Hello,

I have a project that I have developed using GLFW3 for OpenGL which more or less works and now I need more advanced functionality like menus, toolbars, etc.

It seems to me based on research that QT and wxWidgets are the best all-around libraries for cross-platform development for this task.

My question for the experienced developers here is which one?

I realize that some may say that it is a matter of comfort between the two but my focus is more about performance, support in the future from the respective development communities, and functionality.

Feedback is appreciated. Thank you for your time.

I had the same issues, so here are my thoughts:

- With QT there is one additional step, because QT uses an inhouse "mid" compiler. So whenever you use QT only libs, headers and sources won't cut it.

Before building the solution you have to use the QT compiler to build the GUI stuff. This can be very frustrating. So it won't be only code & play. You

will have to update your tool chain too.

- vxWidgets has one major design flaw: it supports no delegates. Which means: for every GUI object you create, you have to define a new class. Not an instance. A new class.

So if you have 3 buttons, you have to define 3 classes to handle their messages (class button1 : wxObject, class button 2 : wxObject etc...)

Maybe you could go with "crazy eddie's" GUI which runs inside OpenGL ?

http://cegui.org.uk/

Or maybe you go the .net way?

Widgets does have its own delegates called events, you can call Connect() (Bind in newer versions) to connect a function to an object id, the object is used the function is called. The function doesnt have to belong to a unique class, it can be a previously derived class. It also has an event table that is similar to how MFC works.

class ClassButtonLivesIn : public ...

{

wxButton* someButtonNotDerived;

}

// in ctor ClassButtonLivesIn

someButtonNotDerived->Connect( wxEVT_COMMAND_BUTTON_CLICKED, wxCommandEventHandler( ClassButtonLivesIn::OnButtonClick ), NULL, this);

and then call Disconnect() later

- vxWidgets has one major design flaw: it supports no delegates. Which means: for every GUI object you create, you have to define a new class. Not an instance. A new class.

So if you have 3 buttons, you have to define 3 classes to handle their messages (class button1 : wxObject, class button 2 : wxObject etc...)

Just to clarify what the above poster said, the above 'design flaw' is false.

OK, so to clarify you don't need to set up multiple classes per button?

That seems like an odd thing to do.

I had the same issues, so here are my thoughts:

- With QT there is one additional step, because QT uses an inhouse "mid" compiler. So whenever you use QT only libs, headers and sources won't cut it.

Before building the solution you have to use the QT compiler to build the GUI stuff. This can be very frustrating. So it won't be only code & play. You

will have to update your tool chain too.

- vxWidgets has one major design flaw: it supports no delegates. Which means: for every GUI object you create, you have to define a new class. Not an instance. A new class.

So if you have 3 buttons, you have to define 3 classes to handle their messages (class button1 : wxObject, class button 2 : wxObject etc...)

Maybe you could go with "crazy eddie's" GUI which runs inside OpenGL ?

http://cegui.org.uk/

Or maybe you go the .net way?

I guess the other commenters are correct in noting that QT's build setup is just a one time thing so that isn't so bad.

I guess the larger question(s) are things like start-up times with applications and performance while using said applications.

I researched Crazy Eddies GUI and it seems that the system is one ot two steps away from being ready for usage with a complete project. Good for a simple menu but not good for things that you would need in a complete GUI package. Good suggestion though, this might be useful in combination with other things.

Coming back to QT and setting aside the development build setup are people's overall opinion on QT more favorable that wxWidgets?

Coming back to QT and setting aside the development build setup are people's overall opinion on QT more favorable that wxWidgets?

Consider this: there is an entire Linux desktop environment based on Qt (KDE). Canonical, the company behind Ubuntu, has dumped GTK as their toolkit of choice and is developing their new multi-platform desktop using Qt. There is no desktop using WxWidgets.

WxWidgets is pretty close to a free clone of Microsoft's MFC. Microsoft recommends against the use of MFC and has done so for quite some years now.

You make very powerful points. I have been searching for positive arguments for WxWidgets but it seems that so far QT is better in whichever area that WxWidgets can claim as a strength. Plus there are the glaring weaknesses with it being a "clone" of the MFC platform and not being as fleshed out as QT.