Slashdot Mirror
Digia Releases Qt 5.1 With Preliminary Support For Android and iOS
An anonymous reader writes "Finnish software and services firm Digia, which bought Qt from Nokia back in August, has released version 5.1 of the cross-platform application framework. Among the changes are 'significant improvements' to Qt Quick and preliminary support for Android and iOS. The latter means Qt on Android and iOS are both considered Technology Previews, letting developers start building for the two mobile operating systems and porting apps from other platforms by reusing the same code base. Although most of the Qt functionality and tool integration is already in place to start developing mobile apps, Digia promises complete ports to Android and iOS will come with the release of Qt 5.2 'later this year.'"
Can't wait for that.
Qt could be the answer to rich internet cross platform apps
Aren't Android apps written in Java syntax with a Google version of the JVM?
I do not fail; I succeed at finding out what does not work.
Nokia could have made a compelling cross-platform play. Write one app, have it run on iOS, Android, and Meego -- and others. Like what HTML5-on-mobile was supposed to do, but without the performance and compatibility headaches.
It wouldn't necessarily have a native look-and-feel on each platform but there are plenty of apps that use non-standard themes anyways.
I've been a QT developer for a number of years. Over the last few years, I've done some Linux embedded. A few months ago, I even built and ran a QT app on the Raspberry Pi. Everything worked except for animation. Nokia messed up by not staying the course. And now they announced they are happy being the challenger. Seriously? You were the world dominater several years ago. One thing not mentioned is the Blackberry port. The framework is well done and it just works.
I can see a lot of potential to seamlessly develop native (fast) apps which are ALSO cross platform. It sounds like a win-win for me with the user's usability experience being faster as well as a familiar environment for app developers. As long as they can keep up to speed with the core platform features and changes..
As Apple runs iOS with an iron fist, will QT be a permitted way to develop GUIs for it?
There was a time in April 2010 when Apple changed the App Store Review Guidelines to ban all languages other than Objective-C and C++ as an effort to keep Adobe from offering AIR, its tool to package Flash applications as iPhone apps. When this policy was in effect, MonoTouch would have been banned, and the developers of Unity 3D were even porting the library to allow writing a game in Objective-C. Such a game would share no code with the same game for other platforms, making it yet another DRY violation induced by a platform gatekeeper. Apple reversed this policy two months later after it became clear that this banned the use of Lua for game logic and dropped all language restrictions the following September.
I'm sorry to say that in trying out QT a hello world app involves over 10 megabytes. (I remember doing it in Dos with only 16 or so bytes). Of course it's doing a lot of graphics etc, but if you've got to port the qt system and all the supporting libraries over it will be substantial.
Please correct me if I'm wrong. (I would love to be mistaken about this).
Na, you are wrong. You can of course package a private copy of Qt for Android/iOS/etc with your application but you can also use the shared copy provided by Ministro:
https://play.google.com/store/apps/details?id=org.kde.necessitas.ministro&hl=es
Digia is already working on a "Ministro for iOS" to provide a shared Qt copy for all the apps.
I'm quite sure, given the "free" license of QT is based on LGPL, that a developer will need a commercial license from Digia to publish an iOS app on the App Store :(
Thank you for insulting the other companies and the individuals that work hard on Qt. Digia maybe owns the trademark and the right/obligation to relicense, but is not the owner of Qt, and certainly not the only contributor. See the statistics about Qt created by Thiago Macieira.
The Android port started as a community only project, by the way.
I use Qt extensively, and while there are numerous reasons to sing its praises, the project has a severe problem in the form of not fixing bugs (like file open dialogs dumping huge amounts of console errors) or limitations (like a windows audio sample rate of 48 khz) before proceeding to new versions.
What that causes is applications that are unstable either because the existing bug hasn't been fixed, or unstable because they get moved to an arbitrary new version with many changes -- and very few applications are as extensively tested against the new version as compared to the old during the initial design and implementation phase.
On the one hand, Qt has enabled me to make apps that (mostly) work the same using the same code under Windows and OSX. But it also causes me a lot of angst trying to explain to my users why the OSX version works so much better than the Windows version. It's not that I want it to; the OSX version of Qt is simply better.
Qt isn't the only project or organization guilty of wanting to make new versions before fixing the existing version. The lure of new APIs and such is strong, and the urge to fix bugs apparently not so much, right across the software spectrum. Apple does it; bugs persist for many OS revisions while APIs come (and go... Apple is not shy about telling you to stop using something.) Microsoft does it: I remember the glyph rotation bug (CW on some platforms, CCW on others) and the how-many-files-you-can-multi-select bugs managing to survive over not only OS revisions, but different OS platforms when the MIPS and Alpha versions were being offered. In the interim, Microsoft changed a great deal about window metrics across various OS levels, affecting all manner of interface issues, while OSX inflicts such obnoxious "favors" as not supporting new cameras except with a new OS level (while still happily selling you a version of their image editing that will work on your older OS), and breaking such *NIX components as cron. UDP sockets still don't work correctly under OSX (broadcast reception sockets where only one can exist on a machine... yeah, that's a good idea... not.)
Basically what I'm bitching about and advocating is that if you produce software, you shouldn't somehow magically get to ignore the fact that it doesn't do what you told the end user it would do just because you've released a new version you want them to buy, or even just use. I have NO problem with charging for new features. I don't even have a problem with adding new features to the current version while also fixing bugs, as long as you take care to not break pre-existing functionality. I have a HUGE problem with charging to fix something that was supposed to be working in the first place, or even, as is the case with Qt, not charging, but simply abandoning in place software that is significantly less than it was purported to be. I find adding new features to be insufficient cause to excuse leaving known bugs in place.
And frankly... if we would just seriously commit to fix the stuff we have before we move on, moving on would be a much better experience overall; the codebase would be more stable, the customers happier, and if we could couple that with a sense of responsibility that left existing APIs in place (once you tell someone to use an API, I think it's just awful to tell them they have to stop), I think we'd have a better process, a better end user experience, and a great deal less agonized tech support. When your "it's-our-fault" buglist hits zero, that's when you should start thinking about changes that might involve moving on from the previous version. I see it as an obligation to the end user. Unfortunately, at least thus far, Qt does not.
I've fallen off your lawn, and I can't get up.