41–50 of 52 posts
Earlier quoted context omitted.
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...
Earlier quoted context omitted.
And VLC, and Clementine, and Doomsday, Mathematica, Skype, and Virtualbox...
All of which are absolutely terrible looking applications with broken platform UX on Mac OS X.
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.
Earlier quoted context omitted.
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…
Name please? You know, this community is full of makers, people could get ideas and make your wish become true...
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 in…
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…
"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,…
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.
Earlier quoted context omitted.
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,…
> 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…
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.
Earlier quoted context omitted.
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...
"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…