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.
tl;dr: Qt is very much ahead of Gtk+ and wxWidgets, progress will, at worst, be comparable to that of Gtk+ and wxWidgets.
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.
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.
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.
Yeah with its mixture of CSS/HTML/JavaScript crap that works perfectly across all browsers versions and operating systems.
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.
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.
With Modernizr, JQuery etc you can get 95+% of the features on 95+% of computers.
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.
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)
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...
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...
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...
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.
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...
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.
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.
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);
});
Currently it is the best C++ toolkit for cross platform applications.
Last week I also started a new project using Qt.
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)
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.
Wednesday, December 22, 2010 - Cocotron is alive and kickingI 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.
the carryover is significant but you don't get a Windows 8 port for free.
I don't see any obvious sign of wxPython in there, though. Nothing with "wx" in the name, for example.
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.
Transmission does this and it's beautiful both on OS X and Gnome. Adium does something similar and it's a good mac app.
GTK+ can look just like Windows XP, Windows 7, Mac OS X. It has themeing capability.
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.
It may not be mature enough for the application you want to start now though.
I think you can pick something else if you want to, but the two mentioned alternatives are probably not it.