Qt 5.1 Released With Android and iOS Technology Previews(blog.qt.digia.com)
blog.qt.digia.com
Qt 5.1 Released With Android and iOS Technology Previews
http://blog.qt.digia.com/blog/2013/07/03/qt-5-1-released/
6 comments
Very impressive work, especially with the mobile integration! I hope this will become the next generation of multi-platform development tools, combining performance and flexibility.
However, the Android demo apps are 16MB and 23MB in size, respectively. For the larger one (Introduction to Qt5) the uncompressed sizes are: 9MB of data, 26MB native code, 134KB of dalvik code.
This looks like a major burden for low-end devices, even though I must admit the demo is looking great (and performs rather fluently on my HTC Vision, running Android 4.2.2).
However, the Android demo apps are 16MB and 23MB in size, respectively. For the larger one (Introduction to Qt5) the uncompressed sizes are: 9MB of data, 26MB native code, 134KB of dalvik code.
This looks like a major burden for low-end devices, even though I must admit the demo is looking great (and performs rather fluently on my HTC Vision, running Android 4.2.2).
When silly puzzle games have hundreds of MB of assets it is okay, but this is a lot? Users don't seem to care or all of the "lets recompile our flash junk" that eats 500MB+ wouldn't do as well as they are doing. If app size matters it is usually the assets that need to be trimmed first.
What would be nice if in the app stores they showed how much space your app would you and let you sort on that, give some sort of incentive to reduce your size.
What would be nice if in the app stores they showed how much space your app would you and let you sort on that, give some sort of incentive to reduce your size.
No need to get upset at GP. A lot of low-end Android phones have little internal storage and installing to SD is not a default thing. I'd be that most Android apps are under 15MB and a lot of apps that I use are under 3.
This is what puts me away from using Qt for Android development.
One of the advices of Google IO this year was to try to keep applications small.
According to Google bigger applications are the ones that get deleted first when space gets short. Most of the time are never reinstalled.
One of the advices of Google IO this year was to try to keep applications small.
According to Google bigger applications are the ones that get deleted first when space gets short. Most of the time are never reinstalled.
I consider the memory footprint even more important, though it is hard to find strong relations between APK size and memory use -- except for the "looks like the dev did not care at all" rule.
Regarding APK size, you can do miracles by using ProGuard (even with obfuscation disabled), though it will obviously fail for native code, like in the Qt case.
Regarding APK size, you can do miracles by using ProGuard (even with obfuscation disabled), though it will obviously fail for native code, like in the Qt case.
I just do hobby development on Android.
Day job is actually JVM/.NET/C++ enterprise applications.
Nonetheless, even my device is not swimming on free space, so I do have some care with it. And given my age, I am used to the time when every byte counted.
On my hobby development I tend to do a mix of Java/C++, depending how portable I want to do it.
Day job is actually JVM/.NET/C++ enterprise applications.
Nonetheless, even my device is not swimming on free space, so I do have some care with it. And given my age, I am used to the time when every byte counted.
On my hobby development I tend to do a mix of Java/C++, depending how portable I want to do it.
That's the first official Android release! Too early to complain, but Qt is opensource, you can improve it, even if you don't know programming. Just file a bug or drop a note in the forums and help developers debug.
the QT team in the past constantly improves their codebase, so i believe the numbers will be better. i use qt since 3.1 and see the improvements in general.
Something makes me think that the native code is dynamically loading in the entire QtCore, QtGui, and QtDeclarative libraries to make the native side run.
When you build a Qt app statically you can strip all the unused functions out. But doing it for loading by the Android NDK? That seems a little trickier. You'd need to rebuild the libs specifically for that application.
Maybe there will be a better solution in the future to handle this, but it also seems likely that the native side wouldn't grow much past this size (i.e. 1 line of "hello world" is 26MB but 100,000 lines of real application code would only grow to 28MB.)
When you build a Qt app statically you can strip all the unused functions out. But doing it for loading by the Android NDK? That seems a little trickier. You'd need to rebuild the libs specifically for that application.
Maybe there will be a better solution in the future to handle this, but it also seems likely that the native side wouldn't grow much past this size (i.e. 1 line of "hello world" is 26MB but 100,000 lines of real application code would only grow to 28MB.)
This is actually solved with the Android app Ministro. It downloads and installs qt libraries in shared locations on demand for whatever apps need them, letting you distribute just the app binary, and it will invoke Ministro to get its necessary libraries.
This is awesome. Congrats to the Qt team for a what looks like an excellent release! I can't wait to get my fingers dirty with this.
Also improved opengl and opengl binaries.
Well that's cute.
It's really hard to make a play on words on the internet.
"I wish my apps were written using a poorly integrated non-native toolkit" said no actual user, ever.
Nobody wants a Qt-based application port, for most of the same reason nobody wanted a (Java) Swing-based port. They don't want ports, they want native apps.
The only people who want to provide Qt-based apps are developers that want to put themselves ahead of their users.
[edit] Perhaps downvoters can reference a cross-platform widget toolkit that was successful in the market? So far, Java, Qt, WxWidgets, and Gtk have not succeeded as cross-platform GUI libraries. Are there any break-out successes I'm missing?
Otherwise, I don't see what the complaint is, so perhaps you can elucidate and downvote.
Nobody wants a Qt-based application port, for most of the same reason nobody wanted a (Java) Swing-based port. They don't want ports, they want native apps.
The only people who want to provide Qt-based apps are developers that want to put themselves ahead of their users.
[edit] Perhaps downvoters can reference a cross-platform widget toolkit that was successful in the market? So far, Java, Qt, WxWidgets, and Gtk have not succeeded as cross-platform GUI libraries. Are there any break-out successes I'm missing?
Otherwise, I don't see what the complaint is, so perhaps you can elucidate and downvote.
First off, Qt is native for quite a few Linux GUI desktops. So there's no "port" for those.
But even beyond that, the toolkit you're referring to (QtWidgets) is only one part of Qt itself. In fact I rather doubt you'd ever use it for an Android application, preferring instead QtCore plus the declarative U/I handling.
Much of Qt is code you would otherwise be writing /anyways/, only they did it for you, did it right, and even documented it with examples of how to use properly. For instance, event loops, abstract I/O, Unicode string handling, concurrency, atomics primitives, networking support (including integration into aforementioned event loops and abstract I/O), and much more.
As a side effect of coding to a thoughtful, high-level API you happen to make cross-platform development easier, but that's hardly the only reason to use Qt.
Either way the fact that you don't instantly recognize Qt apps when you see them is proof positive, as they are out there in much higher numbers than you seem to realize...
But even beyond that, the toolkit you're referring to (QtWidgets) is only one part of Qt itself. In fact I rather doubt you'd ever use it for an Android application, preferring instead QtCore plus the declarative U/I handling.
Much of Qt is code you would otherwise be writing /anyways/, only they did it for you, did it right, and even documented it with examples of how to use properly. For instance, event loops, abstract I/O, Unicode string handling, concurrency, atomics primitives, networking support (including integration into aforementioned event loops and abstract I/O), and much more.
As a side effect of coding to a thoughtful, high-level API you happen to make cross-platform development easier, but that's hardly the only reason to use Qt.
Either way the fact that you don't instantly recognize Qt apps when you see them is proof positive, as they are out there in much higher numbers than you seem to realize...
>First off, Qt is native for quite a few Linux GUI desktops. So there's no "port" for those.
That's because Linux has no "native" GUI. It's a hodgepodge of GUI toolkits.
That said, the de facto standard on Linux desktop has been GTK. It's what the major players, that is the most popular distros, support by default.
So QT is only "native" (in the look & feel sense that we're discussing here, not in the runs directly on the machine sense) if you target some marginal distros. Which kind of defeats the whole argument.
>Much of Qt is code you would otherwise be writing /anyways/
Not if you used Google's native SDK.
>Either way the fact that you don't instantly recognize Qt apps when you see them is proof positive, as they are out there in much higher numbers than you seem to realize...
Huh? Who said you don't recognize them? On the Mac they stick out like a sore thumb.
That's because Linux has no "native" GUI. It's a hodgepodge of GUI toolkits.
That said, the de facto standard on Linux desktop has been GTK. It's what the major players, that is the most popular distros, support by default.
So QT is only "native" (in the look & feel sense that we're discussing here, not in the runs directly on the machine sense) if you target some marginal distros. Which kind of defeats the whole argument.
>Much of Qt is code you would otherwise be writing /anyways/
Not if you used Google's native SDK.
>Either way the fact that you don't instantly recognize Qt apps when you see them is proof positive, as they are out there in much higher numbers than you seem to realize...
Huh? Who said you don't recognize them? On the Mac they stick out like a sore thumb.
> It's what the major players, that is the most popular distros, support by default.
You know in the context of everything that's been going on, I really didn't think the "No True Scotsman" for the night was going to be about GTK+.
Sure, if you slice and dice your definitions enough to "toolkit supported by default if I don't run the headless install of distros which coldtea defines as 'major'" then you might come away with GTK+ as a standard toolkit.
But even that wouldn't exclude Qt as a standard toolkit. It gets picked up by the package manager just the same on all major distros, except possibly for Fedora
Apparently everything else is "Marginal" in your book? I'm sorry you seem to take it so personally that you had to whip out the e-penis and establish the supremacy of your chosen toolkit (and the Google native SDK??), but by all means let me step back and stay quiet so you can flex.
You know in the context of everything that's been going on, I really didn't think the "No True Scotsman" for the night was going to be about GTK+.
Sure, if you slice and dice your definitions enough to "toolkit supported by default if I don't run the headless install of distros which coldtea defines as 'major'" then you might come away with GTK+ as a standard toolkit.
But even that wouldn't exclude Qt as a standard toolkit. It gets picked up by the package manager just the same on all major distros, except possibly for Fedora
Apparently everything else is "Marginal" in your book? I'm sorry you seem to take it so personally that you had to whip out the e-penis and establish the supremacy of your chosen toolkit (and the Google native SDK??), but by all means let me step back and stay quiet so you can flex.
>Sure, if you slice and dice your definitions enough to "toolkit supported by default if I don't run the headless install of distros which coldtea defines as 'major'" then you might come away with GTK+ as a standard toolkit.
That _I_ "define as major"? You do know that Linux distributions follow a popularity power law distribution, right? With a few, like Ubuntu, RedHat, etc at the top. This has nothing to do with "subjective opinion".
Don't see why you brought up the "headless install" in the play either -- since just before you said about QT being a native GUI toolkit. QT is not native in a "headless install" either, so those are beside the point.
>Apparently everything else is "Marginal" in your book?
My book again? For one, Linux desktop use is marginal in itself, registering as just a 1% blip. Second, of that, there are popular and marginal distributions. If you don't like marginal, I doubt you'd like Wikipedia's term, which is "fringe".
http://en.wikipedia.org/wiki/Linux_distribution#Popular_dist...
It was a discussion about GUI toolkits, and you made it into a BS ad hominem attack -- as if usage statistics is something unknown that I pulled out of my ass. In short, your argument is bad, and you should feel bad.
That _I_ "define as major"? You do know that Linux distributions follow a popularity power law distribution, right? With a few, like Ubuntu, RedHat, etc at the top. This has nothing to do with "subjective opinion".
Don't see why you brought up the "headless install" in the play either -- since just before you said about QT being a native GUI toolkit. QT is not native in a "headless install" either, so those are beside the point.
>Apparently everything else is "Marginal" in your book?
My book again? For one, Linux desktop use is marginal in itself, registering as just a 1% blip. Second, of that, there are popular and marginal distributions. If you don't like marginal, I doubt you'd like Wikipedia's term, which is "fringe".
http://en.wikipedia.org/wiki/Linux_distribution#Popular_dist...
It was a discussion about GUI toolkits, and you made it into a BS ad hominem attack -- as if usage statistics is something unknown that I pulled out of my ass. In short, your argument is bad, and you should feel bad.
> Either way the fact that you don't instantly recognize Qt apps when you see them is proof positive, as they are out there in much higher numbers than you seem to realize...
No, they really aren't.
No, they really aren't.
You act as if Qt isn't already a successful cross-platform toolkit. Qt has been successfully used for years to make native-looking apps for OSX, Windows, and Linux from the same codebase.
How are you saying Qt has not succeeded as a cross-platform GUI system, or that it produces non-native apps on the platforms it has historically supported?
And yes, my customers -do- want my software to run on Android and iOS just like it runs on Windows, Linux, and OSX - and they don't particularly care in what toolkit it is written. I do, however, care about having to re-write the same code in three different languages.
How are you saying Qt has not succeeded as a cross-platform GUI system, or that it produces non-native apps on the platforms it has historically supported?
And yes, my customers -do- want my software to run on Android and iOS just like it runs on Windows, Linux, and OSX - and they don't particularly care in what toolkit it is written. I do, however, care about having to re-write the same code in three different languages.
Qt works excellently on desktop and is the only realistic choice for native look & feel across Windows and Linux.
I'm pretty sure it's going to be a disaster on Android and iOS because they are so radically different from each other and they don't even seem to have any plans for native L&F, but you couldn't be more wrong when it comes to PC apps.
I'm pretty sure it's going to be a disaster on Android and iOS because they are so radically different from each other and they don't even seem to have any plans for native L&F, but you couldn't be more wrong when it comes to PC apps.
>"I wish my apps were written using a poorly integrated non-native toolkit" said no actual user, ever.
Said the guy who's only had to write single platform, toy apps. Try dealing with complex cross platform apps some day and you will understand why Qt is a great solution at least on the desktop where complexity is much higher than mobile apps which are for the most part toys.
On mobile you have a choice - if your app is more about funky UI than complex functionality - go wild and write straight to native or limit yourself to one platform. But on the desktop - a well designed Toolkit like Qt is godsend and you would be crazy not to use it even for single platform app.
Said the guy who's only had to write single platform, toy apps. Try dealing with complex cross platform apps some day and you will understand why Qt is a great solution at least on the desktop where complexity is much higher than mobile apps which are for the most part toys.
On mobile you have a choice - if your app is more about funky UI than complex functionality - go wild and write straight to native or limit yourself to one platform. But on the desktop - a well designed Toolkit like Qt is godsend and you would be crazy not to use it even for single platform app.
[deleted]
Said the guy whose only written Windows (and maybe Linux) apps.
Is Qt 5.1 poorly integrated with Android? Have you experienced this, or are you simply assuming it?
Working with Qt could be a huge productivity boost for me compared to working with the standard Android SDK. I could have more time available to make it look and work well, and I would be able to reuse core application code (not UI code, mind you) across platforms.
Isn't it premature to declare this a categorical disadvantage for the user?
Working with Qt could be a huge productivity boost for me compared to working with the standard Android SDK. I could have more time available to make it look and work well, and I would be able to reuse core application code (not UI code, mind you) across platforms.
Isn't it premature to declare this a categorical disadvantage for the user?
> Isn't it premature to declare this a categorical disadvantage for the user?
No, we've had about 10-15 years to prove, repeatedly, that "write once, run everywhere" UI never works.
> I would have more time available to make it look and work well, and I would be able to reuse core application code (not UI code, mind you) across platforms.
Qt brings in their own UI code, but if you didn't want to use it, you'd have to bridge to Java via the NDK. Possible, but a lot of work, and involves tossing a lot the value of both Qt and the Android SDK.
No, we've had about 10-15 years to prove, repeatedly, that "write once, run everywhere" UI never works.
> I would have more time available to make it look and work well, and I would be able to reuse core application code (not UI code, mind you) across platforms.
Qt brings in their own UI code, but if you didn't want to use it, you'd have to bridge to Java via the NDK. Possible, but a lot of work, and involves tossing a lot the value of both Qt and the Android SDK.
> No, we've had about 10-15 years to prove, repeatedly, that "write once, run everywhere" UI never works.
That's not what Qt is pitching, at least when it comes to mobile. The idea is that you write your C++ backend in an abstract manner and put platform-specific QML files (which can be developed rapidly, and even WYSIWYG by designer types) on top of it. The idea is not "write once, run everywhere" but "make it easy to cater to different platforms by sharing as much as you can" as well as "make it easy to do that last-mile of platform-specific customization".
You're just having a negative gut reaction against the wrong thing here.
That's not what Qt is pitching, at least when it comes to mobile. The idea is that you write your C++ backend in an abstract manner and put platform-specific QML files (which can be developed rapidly, and even WYSIWYG by designer types) on top of it. The idea is not "write once, run everywhere" but "make it easy to cater to different platforms by sharing as much as you can" as well as "make it easy to do that last-mile of platform-specific customization".
You're just having a negative gut reaction against the wrong thing here.
> No, we've had about 10-15 years to prove, repeatedly, that "write once, run everywhere" UI never works.
Actually, even more than that, given that the first GUIs are from the late 70's.
Actually, even more than that, given that the first GUIs are from the late 70's.
I wish I didn't have to write my f##$@$ing apps in java and then again in objective-C and then again in C# said every developer, ever...
Edit, for your benefit: xamarin, unity.
Edit, for your benefit: xamarin, unity.
Yes. And users still don't care, and they're the ones that pay for the work.
Cross platform UI tools failed in so much as they failed because a) they were reduced to the smallest common set of features of all targeted platforms and b) they failed to provide a look and feel that was indistinguishable from the native toolkit.
Neither of those two seems necessarily unsolvable, however to a certain degree it forces the developer to give up many of the benefits of using a cross platform toolkit in the first place.
Of those two, b) is the more obvious one and the issue that is typically raised. I'm not sure how well Qt5.1 solves it for desktop apps. But looking at my mobile apps, they're already varying wildly in terms of look and fee. I don't think Qt apps will stand out. Mobile platforms are also fairly similar in terms of feature sets, so there's less work to do to solve a), but developers will still have to deal with different handling of notifications, etc.
Neither of those two seems necessarily unsolvable, however to a certain degree it forces the developer to give up many of the benefits of using a cross platform toolkit in the first place.
Of those two, b) is the more obvious one and the issue that is typically raised. I'm not sure how well Qt5.1 solves it for desktop apps. But looking at my mobile apps, they're already varying wildly in terms of look and fee. I don't think Qt apps will stand out. Mobile platforms are also fairly similar in terms of feature sets, so there's less work to do to solve a), but developers will still have to deal with different handling of notifications, etc.
How native are websites? Dont you use them on mobile devices?
How are websites holding up against the native App Store apps for apps?
You can't really compare websites with Qt apps. QML was made from the ground up to allow for building fluid UIs. It is rendered using OpenGL. HTML was never meant to be used for app development, hence the poor experience. Qt and QML is just not native(widgets will look different, etc), but it will perform well. And you can always imitate the look and feel of native OS so apps at least don't look too alien.
> Qt and QML is just not native(widgets will look different, etc), but it will perform well.
Yes, which is not what people want. They want apps that fit in with the larger platform and exploit it's featureset.
We already went through this on Mac OS X. I use a Qt/Mac app every day for work, and would ditch it in a second if a native alternative was produced.
Unfortunately, it's an extremely niche application, and the competition is nowhere near caught up.
> And you can always imitate the look and feel of native OS so apps at least don't look too alien.
That's never worked out well for anyone, ever, in the entire history of cross-platform widget library attempts.
Yes, which is not what people want. They want apps that fit in with the larger platform and exploit it's featureset.
We already went through this on Mac OS X. I use a Qt/Mac app every day for work, and would ditch it in a second if a native alternative was produced.
Unfortunately, it's an extremely niche application, and the competition is nowhere near caught up.
> And you can always imitate the look and feel of native OS so apps at least don't look too alien.
That's never worked out well for anyone, ever, in the entire history of cross-platform widget library attempts.
I worked for a company developing cross-platform Qt applications(we deployed for Linux and Windows though) and all our clients were pretty happy, so I would refrain from the claim "That's never worked out well for anyone, ever, in the entire history of cross-platform widget library attempts.". My example is just one out of hundreds and hundreds of uses of Qt in industry.
If by 'worked' you mean that you were still able to sell it.
It doesn't fit into the platform and nobody actually likes the result, but if you have a market niche, you can get away with it -- until a competitor appears that actually invests in what their users want.
It doesn't fit into the platform and nobody actually likes the result, but if you have a market niche, you can get away with it -- until a competitor appears that actually invests in what their users want.
Qt seems to be working alright for Autodesk Maya and Mudbox. They migrated the UI to it and everyone I've talked to that use these on various platforms don't really have any complaint about the UI (especially since they can use Qt, PyQt, etc... for building plugins).
Also worth mentioning Qt Creator itself I would say.
And VLC, and Clementine, and Doomsday, Mathematica, Skype, and Virtualbox...
Mathematica has a Mac-native frontend, and always has. They've used Qt for the Linux/Unix frontend since 6.0, not sure if they're using Qt for Windows or not.
All of which are absolutely terrible looking applications with broken platform UX on Mac OS X.
Most of which wouldn't even run on OSX if they weren't written in a cross-platform GUI that dramatically reduces development times.
I'm sure the VLC guys would like to spend their days dealing with complicated video codecs rather than the craziness of yet-another-goddamn-GUI-platform.
I'm sure the VLC guys would like to spend their days dealing with complicated video codecs rather than the craziness of yet-another-goddamn-GUI-platform.
Also Sidefx Houdini
> I use a Qt/Mac app every day for work, and would ditch it in a second if a native alternative was produced
Name please? You know, this community is full of makers, people could get ideas and make your wish become true...
Name please? You know, this community is full of makers, people could get ideas and make your wish become true...
Even without using any UI code, having the possibility of writing your entire backend in a cross-platform way is a big advantage. I am rather skeptical about how well Qt UI can work on mobile, but I would definitely use the libraries that cover everything-not-Cocoa.
Java is extremely successful for example Matlab and Mathematica use Java for crossplatform GUI.
Here's hoping that Google doesn't decide to depreciate the native apis on android now there are a few options to write apps that don't involve using their crazy lock-in java api.