Hacker News Reader

Comment by pbsdp | Hacker News Reader

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

View on HN

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

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

> It's what the major players, that is the most popular distros, support by default.

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.

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

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.

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

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.

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.

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

Said the guy whose only written Windows (and maybe Linux) apps.

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?

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

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

OpenGL and Qt both work fairly consistently on multiple platforms.

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.

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

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.

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

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.

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

How are websites holding up against the native App Store apps for apps?

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

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.

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.

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

Mathematica has a Mac-native frontend, and always has. They've used Qt for the Linux/Unix frontend since 6.0, not sure if they're using Qt for Windows or not.

All of which are absolutely terrible looking applications with broken platform UX on Mac OS X.

Most of which wouldn't even run on OSX if they weren't written in a cross-platform GUI that dramatically reduces development times.

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.

Also Sidefx Houdini

> I use a Qt/Mac app every day for work, and would ditch it in a second if a native alternative was produced

Name please? You know, this community is full of makers, people could get ideas and make your wish become true...

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.

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

Reply on news.ycombinator.com