HN Explorer

Ask HN: Time to give up on Qt?

75 points by metaxyy ↗ HN
I'm about to start on a cross-platform desktop app, and I'm trying to choose a GUI toolkit. I was originally planning to use Qt, because it looks great right out of the box, and the API is nice and simple.

With Nokia kicking Qt to the curb, should we all be moving to wxWidgets? Something else? GTK+ still doesn't look very native on Windows or OS X, so for many cross-platform apps it's not a viable option.

71 comments

[ 3.2 ms ] story [ 137 ms ] thread
patrickaljord
Go nativeclient+html5. Best of both worlds. You could still distribute it as a standalone app like https://github.com/adobe/brackets/
zobzu
stuff that runs in chrome? that's not really a desktop app.
eliben
Well, Chromium is FOSS so you can distribute it with your application if that need arises.
zobzu
He specifically wrote that he looks for platform native and desktop app.

I don't think Chrome fulfilling anything here, and Chrome is not FOSS. Chromium is. But then again, that's not what he's requesting at all.

shin_lao
And Windows 8.
vogonj
Windows 8 HTML5 apps are designed completely differently from on-the-Web HTML5 apps and Native Client apps.

the carryover is significant but you don't get a Windows 8 port for free.

shin_lao
Well, event for web apps you have to make sure all the browser work as expected...
paulhodge
That's more like the worst of both worlds, going through the NaCl API is a pain, and debugging a NaCl app is much trickier than usual. It's a ton of work for little benefit, compared to just using Qt.
bitwize
Qt -- particularly the desktop version -- is still being supported and maintained by Digia (and the Qt community).

Digia have been fairly aggressive in insisting that Qt isn't going anywhere and touting the features of upcoming Qt 5.

There really is no better cross-platform GUI library at this time. To jump ship from Qt now, I think, is a fool's move that will create hassle later on down the line.

nuje
The guys doing new stuff are/were working for Nokia though, the commercial support part was split off from Nokia and sold to Digia. Judging from Digia's front page, Qt isn't a big part of the company. Are they interested, rich and capable enough to ramp up staff, expertise and community support to take over Qt development? I haven't paid close attention but how visible have they been in the open Qt development scene?
tikhonj
I don't think Qt is going anywhere. Of course, I'm biased--I use KDE, which is wonderful and uses Qt as the native toolkit. But that is an important point--Qt is used in a bunch of open source projects, and KDE itself is pretty big. I don't see Qt at much of a disadvantage to GTk even if it loses all corporate support.

Personally, I was not very impressed last time I tried to use wxWidgets. Unfortunately, this seems to be the best option for Haskell, and I really want to use an FRP style for my next project. Also, I suspect most of my problems were to do with my not knowing wxWidgets and using the Haskell bindings. (Particularly, I wanted a rich web view sort of widget, but that doesn't come in the standard distribution--the standard one just doesn't cut it.)

So: for most cases, I would advocate Qt over wxWidgets or GTk.

randomdata
Qt is probably pretty hard to beat in maturity, but http://www.cocotron.org/ looks like an interesting project, allowing you to build your OS X applications for other platforms (Windows, Linux).
LukaD
Looks interesting but it claims to be cross-platform and only has a 'Getting started' for OSX.
SoftwareMaven
It a big bowl of "it depends", IMO. Qt is going to keep getting some level of support through companies like Digia[1] and KDE[2]. Especially because of KDE, an entirely open community might spring up around it.

However, I wouldn't bet my own company on it right now. In a year, we'll know where the chips are going to fall. The real problem, of course, is there isn't anything else quite up to Qt's standard.

If this is a for-fun project, patrickaljord's suggestion to use NaCl and html5 isn't a bad idea. I wouldn't do that right now if I wasn't doing it just for fun, though. You are going to get cut up by the bleeding edge there, which is fine if you are trying to push the edge, but sucks when you are just trying to get stuff done.

1. http://www.digia.com/en/Qt/ 2. http://www.kde.org/community/whatiskde/kdefreeqtfoundation.p...

pavlov
Qt may not be a cornerstone of Nokia's mobile strategy anymore, but it's still being actively developed and has wide industry support. Major companies like Autodesk rely on Qt. They're not going to rewrite everything in GTK+ just because of Nokia...

Look for the GUI framework that best suits your purposes now, rather than the one you think is the best long-term strategic investment. If the toolkit sucks, your app is not going to be finished anyway and it won't matter what happens to the framework five years down the road.

eliben
No way. Qt has a huge following of users and community around it, and it also happens to be an open-source project.

If you're worried about commercial support, that's provided by Digia now, and anyhow Qt is used by so many paying customers that other shops will spring up providing commercial support, if the market demands it.

readme
Qt is without a doubt the best cross platform desktop API.
danieldk
Qt is currently probably the best multiplatform native GUI (and non-GUI) toolkit. IMO it got into that position especially because it was always well-funded (via Troll Tech and later Nokia). If Nokia dropped Qt development completely and Digia wouldn't pick up the slack, the pace of development would probably at least be comparable to Gtk+ and wxWidgets, given that Qt is very widely used (from KDE to closed-source software).

tl;dr: Qt is very much ahead of Gtk+ and wxWidgets, progress will, at worst, be comparable to that of Gtk+ and wxWidgets.

jalcine
Your best bet, as many have prescribed here, will be Qt. It works DECENTLY well under GNOME and fantastically under KDE (ofc) if you're concerned about the Linux market, and works pretty well on Windows, too. Personally, with QML and the ability to style applications using stylesheets (not full CSS) and adding scripting support with QtScript is a win-win for me.

However, it really depends probably on the kind of application you're looking to build. If anything (probably silly too), you could build a HTML5 container using Qt, build a API that communicates for native actions and render the rest of the application in HTML5. Better off just making a SaaS, however.

Disclaimer: Hard-core KDE user and FOSS advocate (read: not a freetard)

blub
wxWidgets is not as well supported as Qt, nor is it as mature. I heard that GTK got some updates on Mac because the MonoTouch guys needed them, but the UI is the same as far as I know.

I think you can pick something else if you want to, but the two mentioned alternatives are probably not it.

mseepgood
It's time to give up _cross-platform_. Doesn't work well with the increasingly different UX concepts of different platforms anyway. The only viable cross-platform is the web.
pjmlp
> The only viable cross-platform is the web.

Yeah with its mixture of CSS/HTML/JavaScript crap that works perfectly across all browsers versions and operating systems.

mseepgood
Use toolkits like Extjs, which provide a rich palette of widgets and hide away incompatibilities. http://www.sencha.com/products/extjs/
djcapelis
You realize the Qt basically does exactly that for non-web apps except it's far more comprehensive and tested, right?
jakubw
The difference is that each environment for non-Web apps - Mac, Windows, KDE etc - has each own somewhat well defined look and feel, that applications should follow in order to feel native. That's not true for Web apps in different Web browsers - they are supposed to look the same. Qt compromises that native experience by letting you target multiple platforms. For Web toolkits, at worst you'll end up with an app that doesn't stand out (e.g. by using Bootstrap) but certainly not with one that won't blend in.
djcapelis
I don't know if you've used Qt or not, but one of the things that always impressed me about it was how good it was at defining the abstraction just right at the level so that out of box each platform's app did in fact look right on that platform and fit in with the same look and feel. Obviously that doesn't catch everything, but the areas where Qt apps didn't fit perfectly into the platform's native look and feel by default, it was always easy to insert some platform specific code to go in and call a few functions that brought it up to the level you wanted to see it get to. You know I'm not going to say it's exactly 100% as it would be writing a whole separate app for each platform, but it gets shockingly close with shockingly little extra effort, and as someone who helped write an app using Qt and OpenGL to run on Linux, Windows and OS X on a short timeframe, Qt was amazing.

We're not talking about write once look the same everywhere here like old Java/Swing or a webapp. That's just not what Qt does unless you twist its arm. By default it compiles a version that's intended to fit in on that platform target you compile towards.

And seriously. A webapp compromises the native experience much more than a Qt app would. Pretending you can avoid that by stuffing your stuff in a web browser where there are no cohesive look and feel standards that make any sense and that this is somehow supposed to yield a better user experience?

I don't buy it.

jakubw
I've used Qt a lot. In fact, I'm still a big fan and wasn't trying to sound negative about it in any way. I absolutely agree that Qt does a tremendous job at abstracting away the differences but still, it's the little details that matter and no toolkit could address them all. Things like ribbons on Windows. Multi touch support, cover flow and proper OS X-like multiple window management on Mac. Not to mention mobile. For big applications, these glitches add up and in no time you find yourself resorting to way too many native workarounds.

But my main point was to that cross-browser Web toolkits and cross-platform GUI toolkits are apples and oranges. On the Web there are no UI guidelines. It's essentially free for all. The chrome of the Web browser constitutes a clear separation point between the native experience and the Web experience, which makes it possible for things like Gmail not to feel hostile on Mac, Linux, Windows and any other Web-enabled environment. Whether or not that's good for UX is irrelevant, the fact remains is that Web apps have never tried to integrate seamlessly with the look and feel of the host environment and the users have grown accustomed to that.

pjmlp
With proper operating system integration.
[dead] vlisivka
Extjs does not look and feel like native apps, nor like regular web page.
taligent
If the problems with that "crap" were insurmountable we wouldn't have the huge variety of websites like we do today. And I would argue that just as big cross platform issues exist with Qt/Swing.

With Modernizr, JQuery etc you can get 95+% of the features on 95+% of computers.

pjmlp
> If the problems with that "crap" were insurmountable we wouldn't have the huge variety of websites like we do today

We have them, because many people today don't know how to program in programming languages tailored for desktop development.

The interest in something like node.js is a proof of it.

aculver
Yeah, I agree with this. I still like seeing the discussion here, since I'll concede that there may be some special circumstances and constraints that lead a developer or team to go with one of these cross-platform UI toolkits, but I think on the whole people are better off picking a platform and creating a truly native experience, including exploiting the unique strengths of the platform. Same goes for the cross-platform frameworks available for iOS, Android, etc.
simonh
I''m sure Autodesk, Virtualbox, Google Earth, Mathematica, VLC, Transmission, Scribus, Skype, etc, etc would be very interested to hear how unviable they are.
mseepgood
All of them were started in the past, when desktop programming was still considered a good thing.
notinfinland
Please provide some proof when making such extraordinary remarks. Given their requirements, these companies would have to be insane to try to build their apps with web technologies. Are you really suggesting that they do CAD and VOIP using JavaScript?!
simonh
Native apps, be they desktop or mobile, still very much have their place. The iPhone is irrefutable proof of this. Right in the middle of the golden age of the web, Apple has built a ground breaking native app platform that has taken the world by storm. So much so that even web apps like Google+ and Facebook find themselves in an arms race to provide the best native clients.
raverbashing
The thing is, C++ is hard

Developing interfaces in html/js even factoring the added IE crap is a breeze compared to C++ development. Even with Qt sanding a lot of rough patches

Not that C++ per se is too complicated, rather, building an interface in C++ and doing "a desktop application" with it is a complex task, something that the web model was made to do

Now, for something like a headless application, C++ is fine (and of course it's harder than Python, but not a lot with STL, etc)

mkl
Hence QML. Right now I'm developing a desktop application with the interface done with QML and the main app in C++, and I would say the interface development is easy, as is connecting it to the C++.

The caveat at present is that the standard desktop widgets are not yet fully available from QML (see [1] for a recent update). For most of my application this doesn't matter (I haven't decided how I'll do the settings dialog yet), but for enterprise apps it quite likely does.

[1] http://labs.qt.nokia.com/2012/06/06/desktop-components-for-q...

dkersten
The caveat at present is that the standard desktop widgets are not yet fully available from QML

I hear Qt5 will have have all (or a lot of) the standard widgets available in QML. Until then, using QGraphicsProxyWidget is a quick and easy way to embed QWidgets inside QML. Here's an example: http://qt-project.org/doc/qt-4.8/declarative-cppextensions-q...

I haven't decided how I'll do the settings dialog yet

I would use QGraphicsProxyWidget and this: http://doc.trolltech.com/solutions/4/qtpropertybrowser/index...

mkl
Thanks for the links - didn't know about the property browser thing.

It's not quite as simple as waiting for Qt5. From my earlier link: The components are hosted as a Qt Playground project and won’t be a part of the 5.0 release. They will instead have separate releases, most likely in sync with the Qt 5 releases. At some point we will look at making them a proper part of Qt 5.

These separate component releases will be important, as the proxy widget mechanism won't be available for Qt5's QSceneGraph-backed QML. Nor does there seem to be a replacement coming yet, mostly for performance reasons [1].

[1] http://www.mail-archive.com/development@qt-project.org/msg04...

notinfinland
What is your cross-platform development experience and on what do you base your grandiose assertion?

I must ask because this just looks like webapp kool-aid. I am increasing my own investment in webdev and I still completely disagree with you.

pjmlp
I would keep using Qt.

Currently it is the best C++ toolkit for cross platform applications.

Last week I also started a new project using Qt.

Jarred
This is something between desktop and web, but you could use Chromium Embedded (http://code.google.com/p/chromiumembedded/). It uses GTK+ on Linux, Cocoa on Mac OS X, and it's own library on Windows (but it looks identical to Windows' UI elements).
zoobert
@Jarred. Thanks for sharing about the CEF project. I need to build a cross-platform GUI in Python if possible and wanted to use wxWidgets with the python binding. Now CEF seems really great: The possibility to make an HTML5-Javascript App and having also the opportunity to deploy it on a web-server is really exiting. I will have to evaluate it, seems really cool. Can you access files on the file system as a normal native application or do you have to write in a dedicated sandboxed area ?
feronull
Adobe Bracket(https://github.com/adobe/brackets/) are using it and they are editing files from the disk. From looking at the source of their implementation I think that this is how you access system functionality https://github.com/adobe/brackets-app/blob/master/src/win/ce...
jarek-foksa
Those two flags only enable local file access via XHR, you still have to know the exact path to the file and you can't write anything. It would be less tricky and more secure to just handle file i/o with native code.
zoobert
@feronull @jarek-foksa. Ok thanks for the info. I agree with jarek-foksa it is still a bit tricksy and I would prefer to access the file i/o with native code. What does it means ? Do I need to build my own "file i/o" lib in c to interface with it ? Does it exist somewhere ? Would you have an example ? Many thanks
jarek-foksa
You have to implement a bridge between JavaScript and native environment that will allow you for passing messages between them.

This is already done in Brackets, you could just copy/paste the code from https://github.com/adobe/brackets-app/blob/master/src/win/ce... and https://github.com/adobe/brackets-app/blob/master/src/win/ce... as it's under MIT license.

With the bridge in place you can access files from JavaScript as follows:

  brackets.fs.readFile('path/to/file.txt', 'utf-8', function(file) {
    console.log(file);
  });
There are also corresponding methods for writing files, deleting files and reading whole directories.
dudus
Qt is the best cross-plataform GUI Toolkit.

But it still feels odd on Windows, and OSX, and Linux (provided that most Linux users are on Gnome these days).

I would rather spend twice the time coding it for native Windows forms and OSX Cocoa.

fceccon
Provided enough resources I think the best approach is writing a library in C/C++ for the core and then using the native toolkit for the GUI.

Transmission does this and it's beautiful both on OS X and Gnome. Adium does something similar and it's a good mac app.

kristianp
I was interested to see the claim that the dropbox client uses wxWidgets (actually wxPython) on this page: http://www.wxwidgets.org/
tzs
Looking at /Applications/Dropbox.app on my Mac, I do indeed see Python 2.5 in there, so it seems they are indeed using Python.

I don't see any obvious sign of wxPython in there, though. Nothing with "wx" in the name, for example.

silon3
I wonder of Qt will lose popularity elsewhere just as many people migrate from Gnome to KDE (I did, at least for the default installation desktop where I don't run alternative WMs).
kimmel
> Something else? GTK+ still doesn't look very native on Windows or OS X, so for many cross-platform apps it's not a viable option.

GTK+ can look just like Windows XP, Windows 7, Mac OS X. It has themeing capability.

veeti
No, it really can't. Every single GTK+ app I've used in Windows has looked terrible and has behaved in very strange ways compared to native UI's. It really makes no attempt to fit in: just as one example, see the dialogs in every GTK+ app. That file picker needs to die. The buttons are in opposite orders.

Qt technically doesn't use the native UI widgets either, but it does a much, much better job at emulating them (and the visual side is completely flawless at least on Windows). In addition, it actually proxies to native functionality where available, which means that you get the real file picker of your platform, dialogs have the correct button order, etc.

GTK+ is only good for GNOME. This is why I wish that Qt would become the de facto standard toolkit for Linux developers: it fits in perfectly in both KDE and GNOME. (Actual KDE apps that use their libraries are a different story, though.)

I've never had anything to complain about the UI of Qt apps on any of the desktop platforms I've used them on. Qt is the best choice for cross-platform UI.

jarek-foksa
You can skin GTK widgets, but it's like putting lipstick on a pig. For truly native look you would have to reimplement most widgets so that they follow OSX HIG.
smeg
If your looking for a powerful canvas feature, qt is really your only choice. That's what swung me away from gtk and wx.
mahmud
I'm seriously considering XULRunner for a cross-platform desktop, "enterprise" app.
saghul
Qt is not going anywhere. I recently attended Akademy and the current QtCore maintainer, Thiago Macieira, showed some interesting stats: over 40% of the commits in the past few months (IIRC) came from non Nokia people.
dman
You could have both wx and qt - check out https://github.com/enthought/enaml . Enaml is a python based UI toolkit which makes writing cross platform UI's ridiculously easy.

Heres a clone of osx preview written in about 250 lines of code -https://github.com/enthought/enaml/tree/master/examples/prev....

Enaml has qt and wx backends. Layout is constraint based and uses the same Cassowary algorithm used by iOS. As a result ive had the incredible experience of writing UI's and have them perform identically on windows, mac, linux and freebsd. Also since the sizing is handled by Enaml itself, the same ui can be run on both wx and qt and will appear identically sized.

Disclaimer: I work at Enthought and am friends with Chris Colbert who is the primary author of enaml.

[dead] johnconroy
Disclaimer notwithstanding, sounds sweet
bratsche
I did a lot of work on the Win32 backend for GTK+ a few years ago, but then when I started at Canonical I stopped working on that. Nobody else really picked it up either. Tor Lillqvist was the original developer of this, and I think he's basically stopped working on it as well.

It's been awhile since I used wxWidgets, but I had an absolutely awful time with it. Honestly if Qt wasn't around, I would choose to contribute to GTK+ to get it back into shape rather than be forced to use fucking wxWidgets.

If I were in the situation of needing to work on a cross-platform GUI app again, having the experience I already have with GTK+ and its Win32 backend, I would choose to go back to contributing to the Win32 backend and write my app using GTK+ (or probably Gtk# with .NET and Mono). But if I were in your position and did not already have both the experience with the Gdk backend and the predisposition to use GTK+, I would absolutely use Qt.

stewie2
Never! wxWidgets is too ugly. And it's similar to MFC. GTK+? I never got GTK+ compiled, there were so many dependencies, so many linking errors.