Cross platform arena: Qt vs wxWidgets

[ZuLuuuuuu]

I see what you mean now. I thought you meant that wxWidgets & C++ don't need additional libraries, because your use of the work "install" seemed to use no particular context.

However, what you've said about GTK & C isn't correct. If you have GTK sources and the libraries, you can link them statically or distribute them with your application. The same as wxWidgets or QT. I know there is an installation program for GTK, but that is not the only way to distribute GTK if you're a programmer.

Sorry, I guess my English is not enough to understand your first paragraph

But I understand the second paragraph heh, yes I forget to add that you can also bind GTK as a static library but I talked as the most popular approach of developers/tutorials out there because I heared that if you bind GTK as statically then the software wents huge, example 7MB just to say hello world. I didn't tried that though...

[samjh]

Sorry, I guess my English is not enough to understand your first paragraph

Nevermind.

But I understand the second paragraph heh, yes I forget to add that you can also bind GTK as a static library but I talked as the most popular approach of developers/tutorials out there because I heared that if you bind GTK as statically then the software wents huge, example 7MB just to say hello world. I didn't tried that though...

Yes it would be quite big. But you have the same problem with wxWidgets and QT as well. The wxWidgets shared library for Code::Blocks, for example, takes up a very large portion of the installation.

You don't need to statically link. You can distribute them as shared libraries with your application.

If you don't understand what I'm saying, here's what I mean in simple terms:

• ALL widget libraries need to be distributed somehow, either as shared libraries or by static linking.
• It is the same for GTK, QT, wxWidgets, or anything else, because MS Windows does not include those libraries (the original poster is concerned mainly about MS Windows).
• So the issue of installing libraries or the size of executables after they've been statically linked, is not important.
• Because they all need to be distributed with the original poster's software regardless of which widget library he chooses.

[Vadi]

Yep you nailed it.

I'm leaning towards Qt, since I'm learning it anyway for another KDE/Qt based project I'm helping to work on. But, someone mentioned iffiness with Qt on Windows. Does anybody have any experience with this?

[Pharaoh Atem]

The reason why Code::Block's wx library is so large is that they chose to do monolithic library building. For an IDE, this is ideal. However, in most apps, it is satisfactory to use the microlithic library style, where each section of wxWidgets is componentized into a separate library.

Qt is the same, although I believe they do not offer a monolithic library for their system. Qt4 has support for native widgets since 4.3.x I believe. And Qt 4.5 will have support for Mac's Cocoa API as well as Carbon.

In any case, if you want to implement all parts of it in a uniform cross-platform manner, I would suggest Qt 4.5. But, if your code has the backend split from the GUI/frontend, then I suggest wxWidgets, since it is easier to work with on componentized applications, in my opinion.

[Vadi]

This is an old topic. Since then, I realized that GTK is also cross-platform, and it's Glade designer for interfaces beats the Qt Designer and wxGlade hands down - so I went with it. Works great on both Linux and Windows.

[bln102]

wxWidgets seems draw custom widgets (button, skins...) in native.

http://wiki.wxwidgets.org/Painting_your_custom_control
http://wiki.wxwidgets.org/Drawing_on_a_panel_with_a_DC

[JordyD]

wxWidgets seems draw custom widgets (button, skins...) in native.

http://wiki.wxwidgets.org/Painting_your_custom_control
http://wiki.wxwidgets.org/Drawing_on_a_panel_with_a_DC

Actually, Qt now draws widgets using the native platform's toolkit as well. And I think it does a better job at it. When I use wxWidgets apps, I know they're wxWidgets apps. But when I use a Qt app, I can't tell.

This is how it works out (in my experience):

                   Windows              Mac             GNOME         KDE
GTK                not native*          not native*     native        native**
Qt                 native               native          native**      native
wxWidgets          native***            native***       native***     native***

* Can look native with proper theming
** IF you use a specific theming engine, and even then it looks a little out of place
*** Looks native most of the time, but has little quirks, like the toolbars not fitting in and windows not sizing correctly.

That said, Qt + C++ has more documentation, plus a neat IDE, so I prefer it.

[pelle.k]

Necromancing, are we?

Anyway, i'm very pleased with wxpython. Looks great as both as gtk and windows applications if you ask me. It can be a bit quirky at times. I'm not too fond of the API (wxpython) documentation though.
I'm using the latest wxformbuilder (from PPA) that does python code generation, so that's pretty comfortable.

I would be using PyQT4 if i didn't have to pay for the licence, should i decide to make a commercial app though. The C++ bindings are free to use in that situation, though. I'm just not very keen on leaving python just yet!

[JordyD]

Necromancing, are we?

They started it.

[Vadi]

I've stuck with GTK+ in the end. Looks okay on Windows (see latest Mono crusade posts), native on Mac (ported from X11), and Glade is much more usable than Qt Designer. Plus the level of support in #gtk is > #qt where the knowledgable people apparently don't hang out and you get suggestions like "try breaking the layout and redoing it again. helps sometimes".