Hacker News Reader

Comment by JupiterMoon | Hacker News Reader

Just curious. Why not go for QT for the whole GUI on all platforms?

Unity only uses native UI systems for Window management, input handling, and menus/file dialogs. The rest of Unity's UI is intentionally written in Unity's own GUI.

We chose GTK over QT for Linux because Unity 5.1 ships with CEF (https://en.wikipedia.org/wiki/Chromium_Embedded_Framework) as the embedded browser and CEF already pulls in a dependency on GTK).

Because native GUI on Windows and OSX is better for those users and already exists?

I'm new to GUI programming and foreign to both Windows and OSX so please forgive my ignorance.

In what way are the native GUIs better? Are they faster/more responsive or do they look better?

Which would be more work over the e.g. 1,2 and 5 year period maintaining three guis or one? (Or is QT not quite cross platform so one ends up maintaining three inferior versions anyway?)

They behave exactly the way you'd expect, because they don't attempt to copy the expected behaviour. They define the expected behaviour.

Not in this case. Unity's editor has a very "unique" UI. It doesn't try to follow OS-specific conventions most of the time.

https://youtu.be/DEumkKjE2YQ?t=8m15s

Until your user has your program installed on e.g. mac and windows and now it works differently on each...

This is actually an annoying problem. As a linux user lack of consistency between apps is frustrating but similarly I know people that struggle with changing from mac to windows regularly.

Qt is cross platform. The difference is that there are UI rendering (say, scaling) behaviors the native toolchains use Qt does not. It comes as close as possible within its widget layout engine it can get away with to native on every platform it supports (which when you consider thats everything from Android to Windows is a feat) but is never a perfect reproduction. Its not something that is going to be "work" for you - you just aren't going to fix it. You get a portable codebase without any of the if WIN else OSX soup, but the experience will never be perfectly native. Though nowadays I don't even know what native Windows means anymore, is it that ribbon crap, or the metro thing? Because Qt apps just use oldschool Windows Forms style menubars / buttons / etc.

You can just go test it yourself, go run VLC and see how "native" it feels. Its using Qt everywhere except Android.

But if you want to develop cross platform native looking software... Qt is absolutely it. Only option. And it gets better each release. Otherwise you are going the route of the Unity guys, rewriting your program for every single system.

> But if you want to develop cross platform native looking software... Qt is absolutely it. Only option.

If you want to develop cross platform native looking software, Qt most certainly is not the only option, wxWidgets is. In fact, as you yourself pointed out, Qt isn't really native, just tries to fake the native look and feel. wxWidgets actually is, as it's a thin wrapper around the native toolkits.

I think native UIs are overrated and just cause headaches for developers. E.g. take the most popular UI system: HTML/CSS/JS: users have no problem with the fact that all their favourite websites look different.

IMHO it is a better idea when the application enforces the same UI across platforms (like QT) than the platform expecting the same UI for all programs. On top of that QT does support native look&feel.

Theres a major difference between a website and a native application. I'm used to websites having no consistency and having elements all randomly over the page. I'm only there for a few minutes, after all.

A lot of productivity software uses Qt. If it were not using native look and feel it would piss everyone and their grams off when system level keyboard shortcuts didn't work, when menu bars weren't oriented system native, when it didn't use the system file dialog, etc. Integrating with the OS is essential to workflow unless the application literally is your entire workflow.

The truth is Mac user expect a Ui to look and feel native, otherwise you will be savaged in reviews, no matter how good your feature set.

You last sentence tells me you have never used a QT app on a Mac, because it does not look and feel native.

There are ones that don't (Quassel for example) and there are ones that do (VLC for one). At the end there is always some polish a developer needs to do, no matter how awesome the toolkit gets. If the developer won't do that, your app will look crap. And its not just OSX, you write your Qt app on Windows and then you run it on Linux, you will need some fine tuning to look perfect.

I still prefer it over any other free IRC client for OSX simply because the feature set rocks.

But do the users care? I do not think so. Otherwise a lot of famous websites would have native UI clients.

The iOS AppStore is exactly that. A bunch of native UIs for famous websites. E.g.: Facebook, Twitter, Google Apps...

Precisely because users (at least iOS and Mac users) do care.

Yeah, but mostly because these applications do not work properly on mobile devices (smaller screen size, too slow, etc.) and a native (in the sense of NOT browser-based) application makes sense. However my hypothesis is just, that the LOOK does not have to fit into the OS.

Absolutely. A QT/GTK/Java UI framework is immediately noticeable on OS X, and IMO even Windows though to a lesser extent.

Doing native is without a doubt the right call.

Its not nearly as bad as you make it seem. Also you can embed objective c and native cocoa widgets in Qt apps so you cam make it as native as you want.

There is some insane technical debt maintaining three versions of your application with platform specific plumbing. It almost never is worth the investment to become portable after the fact, but when you start out it always strikes me as incredibly shortsighted to lock yourself into a native toolkit in the first place when Qt is so good nowadays.

You could also make this argument in the other direction: it's incredibly shortsighted to lock yourself into Qt when there are some things you can do only with a native toolkit. Using native libraries on each platform gives you flexibility and intra-platform consistency at the expense of lots of extra effort. It really just comes down to whether you're willing to expend this effort or not.

What are examples that you can just do with a native toolkit?

One example that comes to mind is adding custom force touch events on Apple's new trackpads.

Probably because Unity was a Mac first program. The Windows version came when it was 2 or so i think.

It seems Gtk has won, why don't the QT developers and supporters move to the Gtk camp and work to make it better rather then keep QT alive which just wastes efforts.

I'm new to this but I thought that QT is more convenient to use on windows and osx?

Because for professional development, there's really no comparison; Qt is on a different level from GTK entirely. I just did a keyword search on Monster India - Qt: 69 jobs, GTK: 3 jobs.

Yeah, just about the only reasons to use GTK+ in new projects are the plain C API and slightly better bindings. Qt bindings support deteriorated a little from Qt 4 to Qt 5 (python is there but still no java bindings as far as I can tell), whereas GTK+ isn't expanding in features so it doesn't get to have such problems.

"Gtk has won" [citation needed]

It has essentially won on linux, where Qt is limitted to the KDE subculture and cross platform apps for which linux is not a priority. GNOME, Unity, Pantheon, XFCE, LXDE, Mate, Cinnamon, etc. all work best with GTK. With some of the heavier weight desktops, Qt apps look quite out of place, kind of like how cross platform UI apps look on Mac and Windows.

Since most Qt apps on linux come from the KDE ecosystem, they often pull in a lot of KDE dependancies, which means a lot of extra packages lying around your system, creating clutter, which might bother some people. The relatively heavyweight nature of most Qt apps makes them less appropriate on systems that use just a window manager rather than a full desktop environment.

Sure, a lot of GTK apps pull in a bunch of GNOME dependancies, but there's also a large contingent of GTK apps from the lighter-weight XFCE world that don't.

Outside of linux, Qt has won pretty decisively, mostly because the GTK developers aren't interested in making GTK apps look good on Mac/Windows, so long as they run.

You can use gtk styling in Qt apps and it looks just like GTK. Also Ubuntu Unity is switching to Qt for unity 8. As for dependencies, there are definitely more Qt apps on linux than just KDE apps.

Plus "KDE apps pull a lot of deps" claim is already outdated, as recent releases of KDE Frameworks are highly modularized.

Not sure that this is true on the ground as yet. I guess it will filter from upstream to LTS distributions over the next few years.

Although I don't actually mind as I find that once you've got one KDE app you end up installing more as they are often quite a lot better (for me) than Gnome ones - and disk space is pretty cheap these days anyway.

Interesting answer. You left out that Ubuntu's recent SDK has a strong relation with Qt.

https://developer.ubuntu.com/en/apps/

The "out of place" argument is one I commonly used by Mac and Linux users because they want everything to look native in their OS of choice and disregard dev time (to use a different window framework for each OS) and look in every other OS.

No one can win that argument to favor THEIR own OS look over another.

Qt apps are pretty reliable across platforms and are speedy to develop so that's what should be important instead of getting an impossible native look.

Won what? Qt is widely used and has a big community. Qt now supports mobile devices as well and the framework development is very tidy and fast.

Besides, the whole "wasted effort because there's 2 projects that 2 similar things" is a fallacy.

As a Qt developer let me give you a big resounding no and ask you a question: Have YOU developed with Gtk in Windows?

Reply on news.ycombinator.com