QT vs wxWidgets

Question

The question has been asked before, but the most recent one seems to be from two years ago, so there must be new developments that must have occurred in the two toolkits.

So which toolkit should I use for developing a GUI with C++? What are the pros/cons of each?

Solution 1

In my obviously biased opinion, the advantages of wxWidgets are:

• Native widgets (as far as possible) guarantee native look and feel
• Standard C++ only, no special preprocessor/extensions
• Possible to link statically to closed source applications without buying a commercial licence

Also, whether it's an advantage or a disadvantage is up to you to decide, but wxWidgets is primarily a GUI library and seeks to play well with the other specialized libraries (like SOCI or asio, for database and network support, respectively) instead of trying to be the one and only true library for everything.

Solution 2

If you are comparing wxWidgets with Qt, wxWidgets literally stands no where. Qt is a complete framework where you can write code and generate GUI for Linux, Windows, MAC, Android, IOS and even blackberry, and other embedded systems. It has classes for almost anything you wish to do, from controlling your webcam to bluetooth devices etc. Unless you are doing something very specific, you won't need any 3rd party library.

On the other hand, wxWidgets, essentially offers a way of creating GUI, with many other classes too but they are quite few in comparison to Qt.

Comments

[Admin]

It really depends on whether your project is open source or closed source. Both toolkits work fine for open source projects. For closed source, QT has all types of restrictions and feature limitations. They charge $350 per month for a license. wxWidgets is free for everyone, commercial or proprietary.

[Sveen]

wxWidgets - Good Community, Perfect Documentation, Free Comercial License

[Pierre]

It is incorrect to dismiss this question as "opinion-based" and "just a matter of taste". There are solid reasons to prefer one over the other. How complete and thorough is the API? Does it implement obscure or arcane APIs that are nevertheless crucial to your app? Ex: Win32 BeginPath/EndPath/FlattenPath. The feedback from experienced users who have tested one or both of the frameworks, is valuable as it can save weeks of evaluation. I'm using Qt, seems pretty thorough, good documentation. wxWidgets seems a little more lightweight. But I'd love to hear from someone who has tried both.

[nairware]

Under the LGPL license, Qt also makes it possible to link statically without buying a commercial license. Unlike wxWidgets' license, however, the LGPL requires that at least the object files (if not the source files) of the potentially/presumably proprietary code be provided to the end user, along with the library source code (in this case, Qt source code).

[Admin]

Of course you could use Code::Blocks or CodeLite to write code and generate GUIs for wxWidgets. And you can build commercial apps without paying the Qt licensing fee of $350/mo.

[adnan kamili]

@TomDworzanski You can build commercial apps in Qt without paying a single penny, LGPL only requires that you link dynamically to Qt libs. You can link statically too but you need to provide object files in that case.

[Donald Murray]

wxDevC++ provides a full visual IDE for C++ wxwidgets. Boaconstructor provides a full visual IDE for wxpython.

[user3658739]

It's true, QT has some widgets that could not be found int the target OS, and that is QT's objective, in the other hand wxWidgets provides all the native OS widgets, if you need a widget not available in the target OS you can implement it on top of wxWidgets and then your widget will be cross-platform (i have done it before for a set of fancy controls and is not too hard).

[user3658739]

I think is otherwise: wxWidgets license: docs.wxwidgets.org/3.0/page_copyright_wxlicense.html, QT License: qt.io/licensing-comparison

[VZ.]

Yes, I hadn't noticed @nairware's comment, but it's absolutely wrong concerning wxWidgets, the exception in wxWidgets licence expressly allows static linking. In theory LGPL allows it too if you provide the object files for relinking, but I've never seen anybody bothering to do it in practice.

[Ari]

but qt is too expensive.

[adnan kamili]

@KeepMove You you don't link the Qt libs statically then you don't need to buy it

[Ari]

that is what I meant, I don't have the freedom I want as a developer if I don't buy the commercial license which is really expensive. And there is also another rule which requires that every programmer in a company using commercial qt should pay for the license. I think qt is no more than an overpriced gui framework, used to suck the money made by the developers.

[Franklin Yu]

@nairware "Qt also makes it possible to link statically without buying a commercial license." You need to provide all the object files if you link Qt statically, according to LGPL, right? Which means nobody would do that.

[user2943111]

@adnankamili I have heard your argument many times before, but I think it is a misinterpretation of LGPL. Even if you link dynamically, your code would not be able to function properly without Qt. As such, it is a 'derived work' and you would have to open source your code OR get a license. That many people don't pay for the license doesn't mean it is right.

[Elijah]

Derived work means modification of the qt library. As long as you are using / dynamically linking to qt, you can keep your source code private. You just have to provide instructions for getting qt source code, replacing the compiled library files and you are good to go. qt.io/faq/…

[rbaleksandar]

Even though I'm just starting with wxWidgets I think that saying it is for GUI stuff only is very incorrect.It has networking, filesystem access, threading etc.Of course it does not offer the vast set of features Qt does but that's not a bad thing really.If you have ever built Qt from source in its full capacity you would also know that it relies on a large amount of third party libraries to provide a great chunk of the functionality you take for granted.In many cases it just creates an abstraction layer that makes things Qt-ish that is more or less consistent with the rest of the framework.