

Ask HN: Time to give up on Qt? - metaxyy

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

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

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

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

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

------
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...](http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php)

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

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

------
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...](https://github.com/adobe/brackets-
app/blob/master/src/win/cefclient/cefclient_win.cpp#L384)

~~~
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...](https://github.com/adobe/brackets-
app/blob/master/src/win/cefclient/brackets_extensions.cpp) and
[https://github.com/adobe/brackets-
app/blob/master/src/win/ce...](https://github.com/adobe/brackets-
app/blob/master/src/win/cefclient/res/brackets_extensions.js) 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.

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

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

~~~
joezydeco
Just curious: what % of the commits are coming from the larger Qt consulting
houses (ICS, KDAB, Digia, etc)?

~~~
saghul
I found the full stats here: <http://www.macieira.org/blog/qt-stats/>

~~~
joezydeco
Very interesting, thank you. I'm amazed how quickly Intel jumped into the fray
here.

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

------
readme
Qt is without a doubt the best cross platform desktop API.

------
haakon
For some perspective, the KDE project posted this today:
[http://dot.kde.org/2012/07/09/kde-rely-qt-protect-qts-
freedo...](http://dot.kde.org/2012/07/09/kde-rely-qt-protect-qts-freedom-
contribute-it)

------
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...](https://github.com/enthought/enaml/tree/master/examples/preview_app).

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.

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

~~~
aaronbrethorst
I would love to see Cocotron do well, but the last post on the blog is:

    
    
        Wednesday, December 22, 2010 - Cocotron is alive and kicking

~~~
Jakob
But their codebase seems recent:
<http://code.google.com/p/cocotron/source/list>

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

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

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

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

------
mattlaver
The XWT framework is worth keeping an eye on:

<https://github.com/mono/xwt>

It may not be mature enough for the application you want to start now though.

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

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

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

------
mahmud
I'm seriously considering XULRunner for a cross-platform desktop, "enterprise"
app.

------
thdn
Take a look at ultimate++

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

