The Qt Company Introduces a Unified Website
blog.qt.digia.com
blog.qt.digia.com
tldr; I like Qt, and I'll use it again.
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.
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.
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.
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...).
[0] https://developers.google.com/open-source/cla/individual
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.
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.
What are those obligations? Can you summarize or give a link? Thanks.
A nice read about it: http://blog.codeimproved.net/posts/qtl-stl.html
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.
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...
I should take another look at it.
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.
Just about any big game studio uses P4 these days. I haven't seen one that doesn't.
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 :-)
([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).
I'm not trying to start a flame war, I'm seriously curious.
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.
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.
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...).
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.
The Phusion Passenger application server is in C++.
Node.js is in C++.
I've always thought that myself. It would be interesting if there were some statistics on that.
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.
I see the desktop applications being swallowed up by C# at the moment.
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.
That said, I wrote the backend to provide HTML5 video over websockets using Qt for my company.
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.
Whether you WANT to write a web app in C++ is an entirely different matter, of course.
I've used it mainly on embedded platforms for UI.
(Having said that, it was a simple concept and easy to grasp)
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?
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.
How is this in violation of the GPL?
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".)
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.
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!
EDIT: Downvoters, please read and answer my replies below before doing so.
Plus, as a commercial company you can still use it for free provided that you abide by the LGPL.
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.
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?
As stated in other reply, open source option not an option as it states I can't publish it in app stores.
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 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.
http://stackoverflow.com/questions/10130143/gpl-lgpl-and-sta...
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 is basically an external app dependency that carries the qt libraries.
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.
Other than that it's quite nice.
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."
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.
http://www.qtrac.eu/marksummerfield.html
He has books for C++ with Qt.
It had a less exciting title though.