Live data from Hacker News

Qt 5.1 Released With Android and iOS Technology Previews

blog.qt.digia.com

31–40 of 52 posts

Re: Qt 5.1 Released With Android and iOS Technology Previews

#31
post #20
post #18

Earlier quoted context omitted.

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.

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 Sidefx Houdini

Re: Qt 5.1 Released With Android and iOS Technology Previews

#32
post #5

"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 cr…

>"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…

[deleted]

Re: Qt 5.1 Released With Android and iOS Technology Previews

#33
post #27
post #26

Earlier quoted context omitted.

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.

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.

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.

Re: Qt 5.1 Released With Android and iOS Technology Previews

#34
post #9
post #7

Earlier quoted context omitted.

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 disad…

> 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…

> 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.

Re: Qt 5.1 Released With Android and iOS Technology Previews

#35
post #3

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 d…

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.)

Re: Qt 5.1 Released With Android and iOS Technology Previews

#36

Earlier quoted context omitted.

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…

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.

Re: Qt 5.1 Released With Android and iOS Technology Previews

#37
post #3

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 d…

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.

Re: Qt 5.1 Released With Android and iOS Technology Previews

#38
post #20
post #18

Earlier quoted context omitted.

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.

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).

And VLC, and Clementine, and Doomsday, Mathematica, Skype, and Virtualbox...

Re: Qt 5.1 Released With Android and iOS Technology Previews

#40
post #5

"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 cr…

>"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…

Said the guy whose only written Windows (and maybe Linux) apps.
Post reply on HN