I don't want to get into the complexity of Qt licenses ever, and wxWidgets does everything I need so far, plus it's 100% open source and free to use. the new release 3.2 is pretty good and it's also smaller than Qt ecosystem, which means much easier for me to learn and start to make releases.
I'm curious way people hate on wxWidgets so much. As a cross platform GUI, it works, and has a better license for developers than QT, and when investigating QT it looked like it requires more than just a library, but QT specific tooling to build things.
wxWidgets. More lightweight than Qt and better looking on Linux. It has improved quite a lot recently, for example it supported binding C++11 lambda functions to signals before Qt.
Also: No moc compiler and you can statically link it without paying for a commercial license.
Desktop app dev feels like a dying art, unfortunately. I see many comments mention Qt, but just wanted to give a shout-out to wxWidgets too. I chose it on a recent project over Qt for resulting in a more lean statically linkable self contained binary, and it also seemed easier to get a native look for all platforms I was targeting.
I'm very interested to hear your opinion on WxWidgets, as I have heard more desktop app devs endorse it over the years. What features makes QT win out over it?
Also, I know this might sound crazy, but what about (f/m)asm?
Not sure on Qt's features as I last used it in the KDE 3.5 days for basic basic apps, but I have used wxWidgets extensively. The Mac port has improved significantly recently, although there are still bugs.
It uses the native UI so fits in better with OSes, whereas Qt ones stand out to me (you can see the buttons aren't native). I did a lot of stuff that was "owner drawn" so reimplemented OnPaint to draw things myself for custom-look controls.
wxWidgets dropped its ODBC support a few years back so talking to databases likely needs another library. Also the ports/HTTP section of it isn't massively useful so I use libCurl instead.
Despite the bugs, it is quick to build and I found working with it enjoyable. Some controls (like the wxDataViewCtrl I think) were really slow so I wrote my own; the OpenGL wrapper works alright but I had to put some work into forcing it to resize; basically be prepared to put some work in - but it is rewarding. I like the layout mechanism - makes other systems like MFC look poor!
You can build wxWidgets and force it to use the STL for its container classes etc; Qt appears to implement everything again instead of just using the existing STL I think.
The developers are helpful and the forum is useful, at least for basic problems.
I enjoy(ed) using it anyway.
It's decent, but I switched to Qt when the licensing changed and definitely do not regret it. YMMV, but I find it the most pleasant and complete GUI toolkit of any language. wxWidgets makes you do more stuff manually. For example, I've found sending custom events to be a fairly complex and error-prone process, requiring badly-documented macros, while Qt makes it a breeze with the signals/slots mechanism. Qt also offers much better integration with VS, eclipse, etc. wxWidgets does have a fairly usable stand-alone designer.
I don't know about dabo, but having used both toolkits, and now that Qt is LGPL, I don't see any serious reason for choosing wxWidgets over Qt. Personally I use it from C++, but if you want Python I'd suggest having a look at http://wiki.python.org/moin/PyQt .
I really want to use Qt for a project but between the absurd commercial cost and them playing games with licensing i'm going with either wxWidgets or Lazarus.
Tk and WxWidgets are not in the same league as QT.
Tk is limited, specifically, to being a gui toolkit, and even though the most recent versions look like native widgets, they are limited and the online support (from groups, etc) is limited. All the connecting libraries feel like you are back in the 90's programming again.
WxWidgets is to QT, as Linux is to Mac OS X -- one is cobbled together from amateurs with varying quality of components, and the other is built by professionals and held to professional rigor. The API (and output, in my opinion) is amateurish and dated in comparison. It lacks the polish and ecosystem that the professionally-supported QT has.
If you are making a full-fledged application (as opposed to a user tool or back-end interface) and are hell-bent on using a windowing toolkit (over say an HTML/CSS engine), then QT is currently the only correct answer. There are others around, but they all fall short of QT.
On a side note, Tcl (by the same original author as Tk) is a wildly under-appreciated scripting language.
It's what I use for my app "Coollector Movie Database" and I'm very happy with it.
Ok, it's C++, but you get a super fast app, and there's no licensing issue contrary to Qt (it's completely free even for commercial apps). I recommend!
I haven't used wx but at least one of the advantages is when exporting a project to .exe I assume you don't need to include the Qt libraries (i.e. .dll files) separately to conform with their licence, it can (legally) be in a single executable.
Qt is great but it's a stretch to say it looks and feels completely native. Open Qt Creator on Windows and tell me it looks or feels anything like a native Windows application.
Qt looks pretty close if you stick to just the essential controls/widgets (text, buttons, text fields). Once you start using other stuff you can definitely tell it isn't a native application. That's not to say Qt isn't good. It's a great toolkit and far, far more complete and featureful than wxWidgets but that's comes as a trade off. The native-backed nature of wxWidgets means you are kind of working with the lowest common denominator a lot of the time which means you don't often get more sophisticated control/widget options. You also have to deal with more bugs between the platforms whereas you rarely have to with Qt.
You have to decide if you want a big, powerful toolkit with commercial backing (and a pretty hefty licensing fee for commercial users) that doesn't quite feel native or a natively-backed toolkit that is less featureful, more buggy, and free.
reply