Qt 5.1 Released With Android and iOS Technology Previews
blog.qt.digia.com
blog.qt.digia.com
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.
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).
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.
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.
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.
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.)
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.
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.
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.
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.
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.
Name please? You know, this community is full of makers, people could get ideas and make your wish become true...
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?
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.
In fact, GL and the native UX interacts poorly, consistently, on both platforms.
Actually, even more than that, given that the first GUIs are from the late 70's.
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.
Edit, for your benefit: xamarin, unity.
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 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.
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...
No, they really aren't.
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.
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.
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.
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.
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.