The Qt Company Introduces a Unified Website(blog.qt.digia.com)
blog.qt.digia.com
The Qt Company Introduces a Unified Website
http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-introduces-a-unified-website-and-20e25-monthly-indie-mobile-package/
150 comments
Which "Lua wrapper API" did you use?
I used lqt from https://github.com/mkottman/lqt.
It worked out great for the project at the time.
I've moved back and forth between QT and raw C++ a couple times. QT might be "bloated", but so will your proprietary program if you create something non-trivial (i.e. a cross-platform application with networking support, threads, font rendering, etc). The bloat has never bothered me that much, but what did bug me was when Digia took over and kind of mangled the code base a bit. It broke a lot of my code, I got frustrated and could not easily find the old version of QT to work with. I think this is a move in the right direction at least...
I've run high performance code on QT without any problems. The DLL bloat is a bit annoying though there are ways to reduce the size of them. However, QT makes threading and concurrency so simple (and cross platform) that I wouldn't go with anything else.
We just switched our system to Linux to avoid Windows' awful file IO and the code compiled (as expected) without a single change. Love it.
We just switched our system to Linux to avoid Windows' awful file IO and the code compiled (as expected) without a single change. Love it.
the problem is not this . the main problem with Qt is , it is not standard C++ library (or framework or toolkit or whatever you name it). All the moc crap ! made it useless .(yes I know , with hacking(or with little changing) it you can use it with other library like boost or anything .
but in my mind this is not right way to do thing !
for example look at which one google chose for chrome in linux (before aura).Google chose gtk++ (which is much inferior than Qt in any ways , and as far as I am aware Qt licence was not issue with chrome) , but it is standard !
for example look at which one google chose for chrome in linux (before aura).Google chose gtk++ (which is much inferior than Qt in any ways , and as far as I am aware Qt licence was not issue with chrome) , but it is standard !
gawd; a tl;dr for a single paragraph. Talk about constrained for memory and flash space and a way to select which components you want to compile...
Note for those looking for commercial pricing - it is sort of hidden under the top buttons in the download page:
http://www.qt.io/download/
That said, just having a publicly listed price anywhere feels like a big step forward for Qt. In the past there was just a "Contact Sales" form with whispered mentions across forums about real pricing. I think this dissuaded a lot of indie devs from trying out Qt.
I'm not sure why this new site doesn't just have a page called "Pricing" that explains what the monthly pricing means. Answer questions like "Do the tools lock out if the subscription is cancelled or do my rights to published statically linked Qt apps get cancelled?" and "Do I have to pay each month to keep those rights even if there is no active development on an app?".
My guess is that Qt must make a bulk of their revenue on enterprise sales and are reticent to open up a self serve sales process (highlighted by the squeeze page they put up when you click the 30 day trial download button). It is a shame because I think Qt could enable a lot of great apps.
http://www.qt.io/download/
That said, just having a publicly listed price anywhere feels like a big step forward for Qt. In the past there was just a "Contact Sales" form with whispered mentions across forums about real pricing. I think this dissuaded a lot of indie devs from trying out Qt.
I'm not sure why this new site doesn't just have a page called "Pricing" that explains what the monthly pricing means. Answer questions like "Do the tools lock out if the subscription is cancelled or do my rights to published statically linked Qt apps get cancelled?" and "Do I have to pay each month to keep those rights even if there is no active development on an app?".
My guess is that Qt must make a bulk of their revenue on enterprise sales and are reticent to open up a self serve sales process (highlighted by the squeeze page they put up when you click the 30 day trial download button). It is a shame because I think Qt could enable a lot of great apps.
The way the license information is presented is a little misleading. The Community edition is described as for 'Open Source & Hobby Projects', giving the impression that its not possible to release a commercial product using that. Thats not true of course, its LGPL licensed and so can be used for commercial software as long as the license obligations are adherred to.
The desktop app I sell uses Qt, against the LGPL license. I would probably pay for the commercial license from them if it was more reasonably priced, but $295 per month to distribute on Mac and Windows is just too much to swallow.
The desktop app I sell uses Qt, against the LGPL license. I would probably pay for the commercial license from them if it was more reasonably priced, but $295 per month to distribute on Mac and Windows is just too much to swallow.
>Thats not true of course, its LGPL licensed and so can be used for commercial software as long as the license obligations are adherred to.
What are those obligations? Can you summarize or give a link? Thanks.
What are those obligations? Can you summarize or give a link? Thanks.
Roughly: link dynamically or provide object files for relinking; don't prohibit reverse engineering of your software (for compatibility with new library versions); don't modify the LGPLed library to require a proprietary component to function.
Thanks, JoshTriplett and FigBug.
Dynamically link to all Qt libraries. Release all changes made to Qt source code.
I missed that subhead and I agree. As long as you dynamically link against the library it's perfectly fine to use it for commercial apps.
Why would someone need/want to use Qt by not dynamically linking the library. I've never understood Qt's business model or what I can and cannot do with it. I just use pyside on my pet projects.
I believe you would purchase Qt for the training and support options, and not so much for hiding a couple of DLLs in the deliverables.
It's also strange that the open-source version doesn't have "Full rights to modify source codes". This is clearly an error.
I think the catch is that, being GPL licensed, any distribution of the software with modified source would be required to be open-sourced. With there commercial license you wouldn't have to release your code. (Though they list GPL, LGPLv2.1, and LGPLv3, you may or may not depending which license it actually is under and how you compile and run your program).
How exactly did they get around the GPL to offer a commercial license anyway? I would have presumed that people doing open-source work on Qt would have submitted their work under only the GPL, and re-licensing that code should be illegal since they didn't write it.
How exactly did they get around the GPL to offer a commercial license anyway? I would have presumed that people doing open-source work on Qt would have submitted their work under only the GPL, and re-licensing that code should be illegal since they didn't write it.
They have an agreement to allow all contributors' work to be relicensed as closed-cource.
Do you have to 'sign' or agree to something before they accept your code then?
Yes. In order to submit a patch though Gerrit, you must agree to https://codereview.qt-project.org/static/cla_individual.html Key is:
Subject to the terms and conditions of this Agreement, Licensor hereby grants, in exchange for good and valuable consideration, the receipt and sufficiency of which is hereby acknowledged, to Digia a sublicensable, irrevocable, perpetual, worldwide, non-exclusive, royalty-free and fully paid-up copyright and trade secret license to reproduce, adapt, translate, modify, and prepare derivative works of, publicly display, publicly perform, sublicense, make available and distribute Licensor Contribution(s) and any derivative works thereof under license terms of Digia’s choosing including any Open Source Software license.
I should note that one further reason for this is to conform with the KDE Free Qt Agreement (http://www.kde.org/community/whatiskde/kdefreeqtfoundation.p...).
Subject to the terms and conditions of this Agreement, Licensor hereby grants, in exchange for good and valuable consideration, the receipt and sufficiency of which is hereby acknowledged, to Digia a sublicensable, irrevocable, perpetual, worldwide, non-exclusive, royalty-free and fully paid-up copyright and trade secret license to reproduce, adapt, translate, modify, and prepare derivative works of, publicly display, publicly perform, sublicense, make available and distribute Licensor Contribution(s) and any derivative works thereof under license terms of Digia’s choosing including any Open Source Software license.
I should note that one further reason for this is to conform with the KDE Free Qt Agreement (http://www.kde.org/community/whatiskde/kdefreeqtfoundation.p...).
Google does the same thing[0] whenever you contribute code to any of their open source projects.
[0] https://developers.google.com/open-source/cla/individual
[0] https://developers.google.com/open-source/cla/individual
One difference is that the Qt source code is also covered by the KDE Free Qt agreement (linked in a sibling comment), which basically acts as a poison pill to ensure that no future owner of Qt can pull an Oracle and close off development.
For this reason, it's my opinion that the Qt CLA is much, much, less onerous than other CLAs, like Google's or Canonical's, in the sense of how much control is actually given away.
For this reason, it's my opinion that the Qt CLA is much, much, less onerous than other CLAs, like Google's or Canonical's, in the sense of how much control is actually given away.
They had desktop pricing for quite a while displayed. It used to be 349$/mo/dev for all three major platforms if I recall correctly.
Does Qt still do that thing where they reimplement a lot of the C++ standard components like Vector? I remember years ago having problems with their reimplementation and wonder how much that's changed.
Yes, keep in mind that some platforms where QT runs do not have the library implemented, have suboptimal performance or is missing functionality. Also, binary compatibility is a big plus on QT.
A nice read about it: http://blog.codeimproved.net/posts/qtl-stl.html
A nice read about it: http://blog.codeimproved.net/posts/qtl-stl.html
Yup, QList, QVector, QString. There are a lot of reimplementations. I tend to find them a lot easier to use than the C++ counterparts. What type of problems were you having?
Nothing impossible -- just integration with the standard library algorithms and some older source code I don't want to modify. It's less difficulty and more a matter of laziness.
I agree. QList is great, it's got very straightforward methods and it's more than fast enough.
QString is a proper unicode-aware string with conversions to many character codecs. It doesn't really compare to std::string.
C++11 has better Unicode support than previous versions.
people don't seem too impressed with it though http://stackoverflow.com/questions/17103925/how-well-is-unic...
Yeps. It sucks when integrating libraries that use the STL, but otherwise they're actually much nicer in many ways. Simpler to use, at the cost of one extra pointer dereference - worth the reduced complexity and error-prone-ness, in many cases.
Yeah. iirc, most of their data structures are COW which can be nice, depending on what your looking for. And, as others have mentioned, they often have a simpler, if less generic, API to them.
The "QTL" still exists, yes. One can use the STL in their code and convert when interacting with the Qt framework (for a price paid in performance)
Yes they do. This is what happens when you need to support a myriad of compilers and OS, with different levels of language support and bugs.
Wow, did I get this right that they have an indie mobile offering now for 20 EUR (without VAT)? This would be fantastic! It used to be 130 EUR.
per month, yes.
How does that work? Do you have to continue to pay the license the entire time that you app is commercially available or is it only during development?
Yep. Only the really-expensive commercial license comes with a permanent license.
We used to have one. It's such a pain in the neck to have to jump through hoops and deal with salespeople for every very-expensive renewal that we stopped renewing. When we want to update next, we'll just use the LGPL version. Opaque licensing plus sales people who don't even have the advantage of being able to negotiate on price is just too much stupid to bear.
We used to have one. It's such a pain in the neck to have to jump through hoops and deal with salespeople for every very-expensive renewal that we stopped renewing. When we want to update next, we'll just use the LGPL version. Opaque licensing plus sales people who don't even have the advantage of being able to negotiate on price is just too much stupid to bear.
800,000+ developers seems like an awful lot. I work mostly on the web - do I just not move in the right circles to meet these Qt developers?
It is the blind spot of the Web/Silicon Valley/Startup world that not all programming is web programming. While the Googles and Facebooks of this world get all the press, there is a stupendous number of developers working on good old-fashioned desktop applications and embedded software. That is the world where Qt is very popular.
In fact, it is my opinion that Qt is the one thing that keeps C++ relevant these days (http://weblog.jeroen.ws/blog/2012/11/19/how-relevant-is-c-pl...).
In fact, it is my opinion that Qt is the one thing that keeps C++ relevant these days (http://weblog.jeroen.ws/blog/2012/11/19/how-relevant-is-c-pl...).
This is exactly my train of thought. But a lot of these developers don't really mind not getting the press---these jobs do pay really well. As far as I know, for instance, C++ game engine developers or people who write powerful, scalable web servers for in-house use make quite a lot of money nowadays. It's a completely different life than the engineers working in risky, fragile startups in return for a high possible payout, but who has it better here is debatable... and a matter of personal opinion, I guess.
Still, writing about Dropbox or Facebook or Stripe or whatever is now hot is way more interesting for the journalists. However, there's no doubt that the guy who wrote nginx or the Unity team (the game engine, not the Ubuntu GUI) made a hell of an impact on the industry, too. It's just that it takes more technical expertise to actually appreciate what these guys have done. That's the reason why most of the people know Steve Wozniak (if at all) as "that guy who worked for Jobs." Not that Facebook or Dropbox or Stripe or Jobs don't deserve the praise, it's just that they've built their empires on technology that also does.
Still, writing about Dropbox or Facebook or Stripe or whatever is now hot is way more interesting for the journalists. However, there's no doubt that the guy who wrote nginx or the Unity team (the game engine, not the Ubuntu GUI) made a hell of an impact on the industry, too. It's just that it takes more technical expertise to actually appreciate what these guys have done. That's the reason why most of the people know Steve Wozniak (if at all) as "that guy who worked for Jobs." Not that Facebook or Dropbox or Stripe or Jobs don't deserve the praise, it's just that they've built their empires on technology that also does.
>It is the blind spot of the Web/Silicon Valley/Startup world that not all programming is web programming. ... there is a stupendous number of developers working on good old-fashioned desktop applications and embedded software.
I've always thought that myself. It would be interesting if there were some statistics on that.
I've always thought that myself. It would be interesting if there were some statistics on that.
There are lots of things that keep C++ relevant, not only Qt.
Such as?
Big PC games are almost always written in C++.
The Phusion Passenger application server is in C++.
Node.js is in C++.
The Phusion Passenger application server is in C++.
Node.js is in C++.
If you count C in the same breath, then between them, they make up the implementation language for probably 99% of other languages, and the operating systems those languages run on.
For anything safety critical, C in particular still has a vice-like stranglehold in many industries (e.g. automobile)
For anything safety critical, C in particular still has a vice-like stranglehold in many industries (e.g. automobile)
> For anything safety critical, C in particular still has a vice-like stranglehold in many industries (e.g. automobile)
Which is kind of ironic, given its well known foot-shooting abilities.
Which is kind of ironic, given its well known foot-shooting abilities.
That's partly why the use it: the problems with C are well understood by many people. They choose the devil they know.
The wonderful language itself, with broad scope for expressing ideas in a terse if not cryptic way. It's great.
Not thought about that, but I suppose desktop apps are where C++ is truly relevant. I am not sure that it is entirely Qt keeping it relevant though!
I see the desktop applications being swallowed up by C# at the moment.
I see the desktop applications being swallowed up by C# at the moment.
That seems about right to me. Qt is very popular among people making physical products on embedded systems and such. The last 3 places I worked at all used and loved Qt.
I just started using PySide which is a Qt wrapper for Python. So far it's been very good. I chose it because I can get familiar with Qt and eventually I may use it in my C++ projects too.
I concur. PySide makes developement/prototyping really efficient : the code is easy to read, no build system to maintain, no heavy tools to run, portability makes life so much better, you can freeze applications => deployment is super easy (well provided you don't have to copy the file on every PC's of the customer :); can't beat the web for that). And plus, Qt is very old and thus mature. It may not be as fun as the web development (which I admit is funnier, at least for the GUI part) but it provides a solid, predictible framework... Now I admit, I didn't play with JQuery which looks very solid too...
Almost all Linux developers have used Qt, because KDE, and Qt has been around a long time; a significant percentage of all C++ programmers have used Qt on one project or another.
Linux developers who write GUI apps. The many people who write server apps are unlikely to have more than user experience.
Speaking of non-gui apps with Qt.
In the past, I wrote a server app that was supposed to be cross-platform (Windows, Linux, Embedded Linux and eventually OSX). I chose to write it in C++ & Qt. That ended up being a bad decision because of the bloat. Since we needed the app to be able to run on embedded systems we couldn't use Qt. (We eventually wanted to be able to run on VxWorks as well). So, the size of the binary was too large. Eventually, I rewrote the app in ANSI C and saved a huge amount in the size of the static binary IIRC ~4MB (Warning, I don't remember exactly). The #ifdef code for each platform was one .c file for each OS with just a few functions on how to start/stop the service etc...
In the past, I wrote a server app that was supposed to be cross-platform (Windows, Linux, Embedded Linux and eventually OSX). I chose to write it in C++ & Qt. That ended up being a bad decision because of the bloat. Since we needed the app to be able to run on embedded systems we couldn't use Qt. (We eventually wanted to be able to run on VxWorks as well). So, the size of the binary was too large. Eventually, I rewrote the app in ANSI C and saved a huge amount in the size of the static binary IIRC ~4MB (Warning, I don't remember exactly). The #ifdef code for each platform was one .c file for each OS with just a few functions on how to start/stop the service etc...
Did you ever try wxWidgets? The OSX support has come on leaps and bounds the last few dot releases.
Not for that specific project no. In the past ~2002 timeframe we used WxWidgets back when it was still WxWindows for a Linux desktop frontend. But other than that, I haven't played around with it lately.
I should take another look at it.
I should take another look at it.
It is worth looking at. There are multiple ways to connect events (signals/slots), and they encourage "Bind" these days, but you can still do Connect/Disconnect or use macro-based event maps (very MFC style).
But in general it's pretty good. There was a GSOC project this year to implement a DirectX backend to the Windows drawing system instead of GDI but I don't know how well that has got on. They overhauled the drawing system to using native drawing contexts on whichever platform you're running, so you can do aliasing etc.
It's worth a look I think, as it is quite easy to write something usable in it very quickly. There is no database support anymore though - wxODBC died a death.
But in general it's pretty good. There was a GSOC project this year to implement a DirectX backend to the Windows drawing system instead of GDI but I don't know how well that has got on. They overhauled the drawing system to using native drawing contexts on whichever platform you're running, so you can do aliasing etc.
It's worth a look I think, as it is quite easy to write something usable in it very quickly. There is no database support anymore though - wxODBC died a death.
Though Qt provides loads of tools useful for writing headless applications. It's not just a GUI toolkit by a long way.
Even among GUI apps, GTK has been until very recently by far more popular.
If you do web work, you likely won't meet anyone doing Qt. I've used it for robot and industrial machine UIs.
Autodesk Maya, Motion Builder, p4v and many others
Although I use git these days and wouldn't go back to P4 if you paid me. I still sometimes use p4merge for my difftool and I always thought they did a great job with their client UI with Qt. So, yay for p4 and Qt.
Funny, while I love Qt, and have been using it in our internal tools, there is a old-lore & myths about p4win (the MFC version) of the tool - that always felt snappier than its successor - p4v - and yes, p4win is snappier, but sometimes its just the fact that you've used it for so long, its hard to get without it.
Just about any big game studio uses P4 these days. I haven't seen one that doesn't.
Just about any big game studio uses P4 these days. I haven't seen one that doesn't.
"Just about any big game studio uses P4 these days. I haven't seen one that doesn't."
That's a very interesting statement. I wonder why? Maybe it's just grandfathered into these companies. IMHO, even if you're an enterprise software shop I think git can handle that with the proper tools and practices.
I'm currently having to use Accurev in an enterprise environment, but I haven't run into anything that Accurev offers that can't be accomplished with git in a better and faster way. But then again, that's just my opinion :-)
I'm currently having to use Accurev in an enterprise environment, but I haven't run into anything that Accurev offers that can't be accomplished with git in a better and faster way. But then again, that's just my opinion :-)
P4, as much as there are aspects of it I hate, handles the situation where you have binary files in the repo much better than most source code control systems do... especially git which sucks at that[1]. Game companies tend to have potentially quite large (by SCCS standards) binary assets mixed in with the code or even when they are cleanly separated, they like to have the standardization of everyone using the same version control system instead of having something separate for the artists.
([1] Predictably someone will probably want to respond to this with some link that shows a complicated and non-intuitive way in which you can get git to be halfway reasonable with handling binary files, though this will just prove my point more than disprove it, when compared to P4 which just handles binary files great out of the box with no thinking or planning required).
([1] Predictably someone will probably want to respond to this with some link that shows a complicated and non-intuitive way in which you can get git to be halfway reasonable with handling binary files, though this will just prove my point more than disprove it, when compared to P4 which just handles binary files great out of the box with no thinking or planning required).
Maybe my google skills aren't as good as others, but can you tell me in what way p4 handles binary files better than git?
I'm not trying to start a flame war, I'm seriously curious.
I'm not trying to start a flame war, I'm seriously curious.
Every time you make a change to a binary file, git will make a copy of the entire thing and attempt to compress it (despite the fact that it may already be compressed as part of the file format and won't compress any further). And because of the distributed nature of git this means each client is going to have who-knows-how-many perhaps barely different versions of each binary asset, which could be megabytes to hundreds of megabytes in length per version and woe be unto anyone who has to clone the repository for the first time when coming into the project (be prepared to wait hours, maybe days).
There are various git methodologies and projects (eg. git-annex) aimed at working around this but by default git just wasn't designed to deal with big repos full of big files.
There are various git methodologies and projects (eg. git-annex) aimed at working around this but by default git just wasn't designed to deal with big repos full of big files.
OK, I get it. The hashing would become slow on each file (especially large ones). And given that git is designed to give you the whole repo history, yes, cloning would be slow with repos with a lot of history.
It seems like 2 of the main reasons Perforce works better with binary files is that when you sync, you only get the version you're requesting, thus resulting in faster downloads and there's an option to disable compression.
According to their website: http://www.perforce.com/perforce/doc.current/manuals/p4guide... Binary files are stored compressed as well. (I assume that there's an option to disable this)
Thanks for the response and information.
It seems like 2 of the main reasons Perforce works better with binary files is that when you sync, you only get the version you're requesting, thus resulting in faster downloads and there's an option to disable compression.
According to their website: http://www.perforce.com/perforce/doc.current/manuals/p4guide... Binary files are stored compressed as well. (I assume that there's an option to disable this)
Thanks for the response and information.
Yes that's exactly correct. On the client-side P4 basically only really cares about the current version (or whatever branched/changelisted revision you are working with) which for projects with a lot of files (especially binary files) will be an incredibly smaller set of data than the full history. git is fully distributed with all of the pros and cons that come with that.
http://en.wikipedia.org/wiki/Category:Software_that_uses_Qt
http://developer.blackberry.com/native/documentation/core/po...
https://www.openwebosproject.org/docs/architecture
plus many specialized niche applications that don't get a lot of press.
http://developer.blackberry.com/native/documentation/core/po...
https://www.openwebosproject.org/docs/architecture
plus many specialized niche applications that don't get a lot of press.
Qt is a GUI framework - it's useless on the web (well, except as a way to learn good UI practice). It's probably the best non-web UI framework I've ever used, on any platform, in any language (its Python support in particular is superb). If I were to write another native desktop application I can't think of anything I'd rather use.
AFAIK Qt is much more than a GUI framework, and even modular these days, so you could leave out the GUI parts if you want. So you can use all kinds of Qt libs for different things, probably even for building a web server.
Whether you WANT to write a web app in C++ is an entirely different matter, of course.
Whether you WANT to write a web app in C++ is an entirely different matter, of course.
I think different frameworks are more popular in different spheres, and yes - I don't really see Qt as being one of the most common frameworks mentioned for web work.
That said, I wrote the backend to provide HTML5 video over websockets using Qt for my company.
That said, I wrote the backend to provide HTML5 video over websockets using Qt for my company.
Guess web is not its circle. ;)
I've used in software for multiplatform oil and gas data analysis and visualisation. I've left the company many years ago, but they still use it heavily.
I've used in software for multiplatform oil and gas data analysis and visualisation. I've left the company many years ago, but they still use it heavily.
Probably not. If you would have interacted with any mobile or desktop Linux developers (especially KDE ones) you would have met more of those who use Qt.
I'm one of those 800000+ devs. I like QT with it's Slots and Signals!
I've used it mainly on embedded platforms for UI.
I've used it mainly on embedded platforms for UI.
Isn't signals and slots just a neat way of doing function pointers, the same as every other GUI toolkit that has callbacks?
(Having said that, it was a simple concept and easy to grasp)
(Having said that, it was a simple concept and easy to grasp)
Is there a modern book which targets a current QT? Last time I was looking (and on Google just now) I wasn't able to find a book that took someone from never having used QT to shipping something.
There's one available online: http://qmlbook.org/
As the name says, it covers basically just QML, but QML is an important foundation of modern QT5 so I guess the book is very nice to have.
[deleted]
The docs site has a lot of tutorials, and Creator comes with a huge examples portfolio. Each example also has a small book about it.
I was under the impression that I could use the (L)GPL version and deploy to various app stores - I wouldn't get support though.
But this article describes "deployment rights", which one would apparently not have access to if using the open source version. A quick google revealed no additional information on this.
Does anyone have any concrete info on deploying mobile Qt apps to app stores with the open source version?
But this article describes "deployment rights", which one would apparently not have access to if using the open source version. A quick google revealed no additional information on this.
Does anyone have any concrete info on deploying mobile Qt apps to app stores with the open source version?
LGPL requires that the user be able to replace the LGPL portion with an updated / modified version. This is usually accomplished with dynamic linking. Since the iOS store requires apps to be signed and disallows dynamic linking, there is no way for the user to modify the LGPL portion. I assume other app stores are similar.
GPL is disallowed for similar reasons, no way for the end user to recompile and app from the app store and run it on their device.
GPL is disallowed for similar reasons, no way for the end user to recompile and app from the app store and run it on their device.
I believe Qt does offer a shared library for Qt that can be shared/upgraded across multiple apps. I wonder if that's enough to allow one to deploy on Android (iOS is obviously a no-go).
I have an early prototype in Qt that's not going to be a big bread winner, but it'd be nice to be able to release it and get some feedback (even if that means that they have to install the shared Qt package too). I'd probably just bail on the idea if I had to pay much of anything, especially monthly.
I have an early prototype in Qt that's not going to be a big bread winner, but it'd be nice to be able to release it and get some feedback (even if that means that they have to install the shared Qt package too). I'd probably just bail on the idea if I had to pay much of anything, especially monthly.
I can make available the source for an iPhone app that could be compiled with XCode.
How is this in violation of the GPL?
How is this in violation of the GPL?
It's not a violation of the LGPL.
The plain GPL is usually said to be unusable on the App Store because it has a clause that "no further restrictions" may be made on the use of the software; that may be fine with you, but when Apple redistributes your app through the App Store, they do it with a EULA that prohibits a wide range of things, so, as the argument goes, such redistribution violates the license. The LGPL does not have such a clause, so it's OK. (It does have a clause that prohibits further restrictions on reverse engineering, but the iTunes terms of use have an explicit exemption to the general reverse engineering ban based on "licensing terms governing use of any open-sourced components".)
The plain GPL is usually said to be unusable on the App Store because it has a clause that "no further restrictions" may be made on the use of the software; that may be fine with you, but when Apple redistributes your app through the App Store, they do it with a EULA that prohibits a wide range of things, so, as the argument goes, such redistribution violates the license. The LGPL does not have such a clause, so it's OK. (It does have a clause that prohibits further restrictions on reverse engineering, but the iTunes terms of use have an explicit exemption to the general reverse engineering ban based on "licensing terms governing use of any open-sourced components".)
Also I believe you could make the object files (before linking) available on your website, and you'd still be fine. If I'm wrong someone please correct me.
On a related note, we are hiring a front end engineer to work on Ubuntu phone and desktop. Stack is Qt,QML, JS and possibly some html5. Could work for a QML dev or a web dev who wants to learn Qt. London based position - email me at [email protected]
The site/message is good, but I'm not sure I would ever promote any in-flight entertainment system as a great example of a development framework in action. Almost every one I've used has been among the slowest, clunkiest, crashiest, most unresponsive, poorly designed "modern" UIs I've ever used.
In order to avoid being entirely critical, however, Qt does serve a role that few other dev platforms do, and although I suspect there are better alternatives, I'm glad that there is still strong support for it!
In order to avoid being entirely critical, however, Qt does serve a role that few other dev platforms do, and although I suspect there are better alternatives, I'm glad that there is still strong support for it!
I had the chance to fly with Delta this summer, the electronics had been updated in my flight, and the UI was great and felt "responsive" in a certain way, let's say 5 times better than before.
The problem you have there is not only one of outdated hardware, but also an issue of software certification and other software red-tape in that industry. A friend of mine was working on one of those systems in the past (IIRC, they used Qt) and it takes a long time for that stuff to get released...
Better alternatives? Please elaborate on your suspicion.
$149/mo to develop on desktop OSes, that is too steep. It pretty much rules out all but big publishers.
EDIT: Downvoters, please read and answer my replies below before doing so.
EDIT: Downvoters, please read and answer my replies below before doing so.
Except you don't have to pay anything if you don't plan to modify Qt itself, which you most likely don't need to do, and even then you just have to release the source to your modification to comply with LGPL.
Not if I want to publish to app stores, as stated in the pricing table that I can't via the LGPL option.
You can use Ministro. See here: http://qt-project.org/doc/qtcreator-3.0/creator-deploying-an...
It is basically an external app dependency that carries the qt libraries.
It is basically an external app dependency that carries the qt libraries.
you mentioned desktop platforms in your OP, so I assumed non-appstore platforms.
Both OSX and Win8 have app stores now.
It's actually $215 for 1 platform, $295 for all 3. Per developer.
That's low compared to the old one which was something like $3k for one platform, $5k for multiple.
If you cannot make $215/month with your software, how can you pay anyone a salary?
If you are non-professional, why not use the open source edition and add value with support?
That's low compared to the old one which was something like $3k for one platform, $5k for multiple.
If you cannot make $215/month with your software, how can you pay anyone a salary?
If you are non-professional, why not use the open source edition and add value with support?
Why do you assume I'm paying someone a salary? I don't even make enough to cover my expenses (just started going indie). For someone like me, $149/mo is way too steep no matter what other options are. It just tells me qt is not an option for me.
As stated in other reply, open source option not an option as it states I can't publish it in app stores.
As stated in other reply, open source option not an option as it states I can't publish it in app stores.
I'm pretty sure that's just a consequence of the LGPL, static linking and how 'app stores' choose to distribute software. If don't want to share your code in a format that allows it to be linked to other versions of Qt, you can't distribute your binaries statically linked to Qt (without paying.)
http://stackoverflow.com/questions/10130143/gpl-lgpl-and-sta...
http://stackoverflow.com/questions/10130143/gpl-lgpl-and-sta...
You can almost certainly just use the LGPL/free version with whatever you are doing on the desktop. So I would say it's still an option.
You would mostly need the commercial version only for mobile deployment due to LGPL having issues with static linking. Support for natively compiled Qt Quick is also a bonus.
You would mostly need the commercial version only for mobile deployment due to LGPL having issues with static linking. Support for natively compiled Qt Quick is also a bonus.
You could use the LGPL version during development and only switch to the commercial license once you go live.
Has the commercial agreement been changed? The terms of the commercial license specifically prohibited that.
It does? But I thought it is possible to use the LGPL version to develop apps. It is just not possible to distribute them through the app stores because of the app stores, not because of Qt. You don't use the app store to deploy the development version of your app onto you development device.
That's all true. However, the commercial license included this:
"You must purchase a Qt Commercial Developer License from us or from one of our authorized resellers before you start developing commercial software. The Qt Commercial Developer License does not allow the incorporation of code developed with the Qt GNU LGPL v. 2.1 or GNU GPL v. 3.0 license versions into a commercial product."
Basically, you have to choose LGPL or commercial before you start your project. You can only transition from commercial to LGPL, not LGPL to commercial.
They do that to prevent specifically the thing you're suggesting, though they're probably aiming it more at large companies with many developers, so those guys don't just buy 1 license.
"You must purchase a Qt Commercial Developer License from us or from one of our authorized resellers before you start developing commercial software. The Qt Commercial Developer License does not allow the incorporation of code developed with the Qt GNU LGPL v. 2.1 or GNU GPL v. 3.0 license versions into a commercial product."
Basically, you have to choose LGPL or commercial before you start your project. You can only transition from commercial to LGPL, not LGPL to commercial.
They do that to prevent specifically the thing you're suggesting, though they're probably aiming it more at large companies with many developers, so those guys don't just buy 1 license.
Ah, I see.
> If you are non-professional, why not use the open source edition and add value with support?
It might be me as I am not a native English speaker but I think "non-commercial" is more accurate than "non-professional" as people can write free software rather professionally and they often do.
It might be me as I am not a native English speaker but I think "non-commercial" is more accurate than "non-professional" as people can write free software rather professionally and they often do.
Personally, I'd prefer a one and done purchase. This pay-by-the month crap is getting out of hand.
Sure, the monthly rent goes to paying for bug-fixes, etc., but those should be in there anyway. It's like buying a car then finding out it still needs an engine tuning and the right wheels to run properly, when they should have shipped with the car.
Sure, the monthly rent goes to paying for bug-fixes, etc., but those should be in there anyway. It's like buying a car then finding out it still needs an engine tuning and the right wheels to run properly, when they should have shipped with the car.
It would be nice if they had an option for startups, a la MS & BizSpark.
That's within the same price point as other leading IDEs.
Plus, as a commercial company you can still use it for free provided that you abide by the LGPL.
Plus, as a commercial company you can still use it for free provided that you abide by the LGPL.
However, I am not able to distribute my apps through public application stores, as marked in the pricing table. Which makes that not really an option.
Also, that pricing tables states only "Mobile application stores". There should be another row for "Desktop application stores" that covers desktop applications, no?
FYI:
Minor site styling bug: http://www.qt.io/download/ 's "Search" bar is too low when scrolled.
Footer text is way too dark to be readable. Default text color should be current highlighted color, while hover should be whiter.
Also, that pricing tables states only "Mobile application stores". There should be another row for "Desktop application stores" that covers desktop applications, no?
FYI:
Minor site styling bug: http://www.qt.io/download/ 's "Search" bar is too low when scrolled.
Footer text is way too dark to be readable. Default text color should be current highlighted color, while hover should be whiter.
It's LGPL as well.
Does anyone have experience with Xamarin AND Qt as well? I am curious how do they compare for cross-platform mobile app development.
I only have experience with Qt, and can tell you that a problem with the current version is the difficulty in getting a native look on mobile. If you want a custom UI, QML is great, but Digia really need to offer native-looking UI components. They will do this for widget-based UIs on Android in the next version I believe, but no word on iOS.
Other than that it's quite nice.
Other than that it's quite nice.
Native UI goes far beyond the look. Another concern is accessibility, especially for blind users. Non-native UIs can be accessible, but only if the toolkit implements each platform's accessibility API, and gets the implementation right, which seems to be very difficult. (For example, last time I checked, Qt's implementation of the relevant accessibility APIs on Windows was deficient enough that the TeamTalk voice chat client offers a "classic" MFC-based client specifically for blind users.)
I don't have direct experience with either Qt on mobile platforms or Xamarin, so I can't provide exactly what you asked for. But I can provide a considered opinion.
I strongly recommend Xamarin over Qt, because even if you use Xamarin.Forms, you'll be using the actual native UI on each platform, not a mere approximation. So your app will be more true to the native look and feel of each platform. Moreover, it will be accessible to users with disabilities, especially blind users, as long as you don't implement any custom widgets of your own. (If you do need to implement custom widgets, you'll need to implement each platform's accessibility APIs as well.) True, these users are a minority, but if you can make your app work for them without considerable extra effort on your part just by building on the right foundation, then that's a win-win situation.
Qt may offer the promise of "write once, run anywhere," but IMO, that should be more like, "write once, be inferior everywhere."
I strongly recommend Xamarin over Qt, because even if you use Xamarin.Forms, you'll be using the actual native UI on each platform, not a mere approximation. So your app will be more true to the native look and feel of each platform. Moreover, it will be accessible to users with disabilities, especially blind users, as long as you don't implement any custom widgets of your own. (If you do need to implement custom widgets, you'll need to implement each platform's accessibility APIs as well.) True, these users are a minority, but if you can make your app work for them without considerable extra effort on your part just by building on the right foundation, then that's a win-win situation.
Qt may offer the promise of "write once, run anywhere," but IMO, that should be more like, "write once, be inferior everywhere."
For all the ruby devs on HN: check out the ruby bindings to qt at http://github.com/ryanmelt/qtbindings. Makes developing GUI apps in ruby really easy. Be sure to checkout the large set of example apps to get started.
I have always looked upon these kinds of projects with interest until it comes to the packaging.
Let us say I create a really super-duper ruby qtbindings application. Is there any way for me to easily package it as a .msi / .dmg / .deb for distribution?
I have messed around with ocra, monkeybars etc and they have never worked or require arcane and undocumented hacks.
Packaging for distribution is the biggest challenge for desktop ruby apps I think.
Let us say I create a really super-duper ruby qtbindings application. Is there any way for me to easily package it as a .msi / .dmg / .deb for distribution?
I have messed around with ocra, monkeybars etc and they have never worked or require arcane and undocumented hacks.
Packaging for distribution is the biggest challenge for desktop ruby apps I think.
Is there a good way to get into Qt? Some getting started blog posts for devs would be very useful, but I've always thought that the Qt learning curve starts with good intentions and then goes vertical. Does anyone have some resources to share?
It depends on what you want to use it for (Qt covers a lot of use-cases) but http://qt-project.org/doc/qt-5/qtexamplesandtutorials.html is probably a good start.
Try this:
http://www.qtrac.eu/marksummerfield.html
He has books for C++ with Qt.
http://www.qtrac.eu/marksummerfield.html
He has books for C++ with Qt.
qmlbook.org, the examples in Creator, the blog the OP post is from has a lot of tutorials on new features as they come out (http://blog.qt.digia.com/).
I love Qt, good to see them promoting it more.
$25 per month is a steal!
Could someone explain this for me please? It's not really clear from the website, but is this any different from the Qt project? http://qt-project.org/
Previously, there was the community-run Qt Project, as well as the commercial Qt (qt.digia.com). Those two projects are now merged. The announcement is here: http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-intr...
This blog post explains it: http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-intr...
Three people replied with the same link. It is clear that that link should replace the originally posted link.
It was posted an hour before at https://news.ycombinator.com/item?id=8324111
It had a less exciting title though.
It had a less exciting title though.
tldr; I like Qt, and I'll use it again.