Live data from Hacker News

Qt 5.1 Released With Android and iOS Technology Previews

blog.qt.digia.com

21–30 of 52 posts

Re: Qt 5.1 Released With Android and iOS Technology Previews

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

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.

Re: Qt 5.1 Released With Android and iOS Technology Previews

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

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

Re: Qt 5.1 Released With Android and iOS Technology Previews

#23
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 worth mentioning Qt Creator itself I would say.

Re: Qt 5.1 Released With Android and iOS Technology Previews

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

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.

Re: Qt 5.1 Released With Android and iOS Technology Previews

#25
post #22
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…

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

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

Re: Qt 5.1 Released With Android and iOS Technology Previews

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

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.

Re: Qt 5.1 Released With Android and iOS Technology Previews

#27
post #26
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…

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.

Re: Qt 5.1 Released With Android and iOS Technology Previews

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

Actually, even more than that, given that the first GUIs are from the late 70's.

Re: Qt 5.1 Released With Android and iOS Technology Previews

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

Re: Qt 5.1 Released With Android and iOS Technology Previews

#30
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.
Post reply on HN