4 ms·

"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

by pbsdp 13y ago

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

dman 13y ago
How native are websites? Dont you use them on mobile devices?
- pbsdp 13y ago
  How are websites holding up against the native App Store apps for apps?
  - kombine 13y ago
    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.
    - pbsdp 13y ago
      > 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.
      - kombine 13y ago
        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.
        pbsdp 13y ago
        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.
        numo16 13y ago
        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).
        coffeaddict 13y ago
        Also worth mentioning Qt Creator itself I would say.
        dman 13y ago
        Also Sidefx Houdini
        zanny 13y ago
        And VLC, and Clementine, and Doomsday, Mathematica, Skype, and Virtualbox...
        pbsdp 13y ago
        All of which are absolutely terrible looking applications with broken platform UX on Mac OS X.
maggit 13y ago
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?
- pbsdp 13y ago
  > 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.
  - dman 13y ago
    OpenGL and Qt both work fairly consistently on multiple platforms.
    - pbsdp 13y ago
      What does that have to do with the platform native widgets and UX? In fact, GL and the native UX interacts poorly, consistently, on both platforms.
  - pjmlp 13y ago
    > 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.
  - sho_hn 13y ago
    > 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.
shadowmint 13y ago
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.
- pbsdp 13y ago
  Yes. And users still don't care, and they're the ones that pay for the work.
morsch 13y ago
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.
drone 13y ago
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.
mpyne 13y ago
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...
- pbsdp 13y ago
  > 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.
- coldtea 13y ago
  >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.
  - mpyne 13y ago
veeti 13y ago
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.
blinkingled 13y ago
>"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.
- deleted 13y ago
  [deleted]
- pbsdp 13y ago
  Said the guy whose only written Windows (and maybe Linux) apps.
frozenport 13y ago
Java is extremely successful for example Matlab and Mathematica use Java for crossplatform GUI.
blub 13y ago
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.

by pbsdp 13y ago

dman 13y ago

How native are websites? Dont you use them on mobile devices?

pbsdp 13y ago
How are websites holding up against the native App Store apps for apps?
- kombine 13y ago
  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.
  - pbsdp 13y ago
    > 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.
    - kombine 13y ago
      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.
      - pbsdp 13y ago
        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.
        numo16 13y ago
        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).
        coffeaddict 13y ago
        Also worth mentioning Qt Creator itself I would say.
        dman 13y ago
        Also Sidefx Houdini
        zanny 13y ago
        And VLC, and Clementine, and Doomsday, Mathematica, Skype, and Virtualbox...
        pbsdp 13y ago
        All of which are absolutely terrible looking applications with broken platform UX on Mac OS X.

maggit 13y ago

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?

pbsdp 13y ago
> 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.
- dman 13y ago
  OpenGL and Qt both work fairly consistently on multiple platforms.
  - pbsdp 13y ago
    What does that have to do with the platform native widgets and UX? In fact, GL and the native UX interacts poorly, consistently, on both platforms.
- pjmlp 13y ago
  > 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.
- sho_hn 13y ago
  > 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.

shadowmint 13y ago

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.

pbsdp 13y ago
Yes. And users still don't care, and they're the ones that pay for the work.

morsch 13y ago

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.

drone 13y ago

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.

mpyne 13y ago

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

pbsdp 13y ago
> 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.
coldtea 13y ago
>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.
- mpyne 13y ago

veeti 13y ago

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.

blinkingled 13y ago

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

deleted 13y ago
[deleted]
pbsdp 13y ago
Said the guy whose only written Windows (and maybe Linux) apps.

frozenport 13y ago

Java is extremely successful for example Matlab and Mathematica use Java for crossplatform GUI.

blub 13y ago

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.