This++
I've used Qt for desktop apps as well as apps on Embedded Linux. I've even used it with a Lua wrapper API that made development even easier.
Is it a bit bloated? Yes. But unless you are very constrained for memory and flash space it should fit in your embedded system. They also have a way for you to select which components you want to compile for your target, allowing you to control how much of the bloat you actually use. :)
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.
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 !
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
Before qt.io was announced I wrote support and asked the same question. In short - yes, you have to pay each month according to them. It's quite reasonable perhaps except for apps that are updated very rarely.
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.
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.
>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.
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)
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.
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...
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.
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.
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."
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 :-)
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).
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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 jouni.helminen@canonical.com
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!
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...
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.
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.
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.)
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.
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.
> 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.
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.
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?
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.
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."
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.
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?
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/).
Guys please ditch the carousel terrible way to convey information when the initial and first piece of information I am trying to absorb is moving around.
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/
tldr; I like Qt, and I'll use it again.