Jump to content

  • Log In with Google      Sign In   
  • Create Account

QT vs. wxWidgets for OpenGL


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 tmason   Members   -  Reputation: 296

Like
0Likes
Like

Posted 11 August 2014 - 09:30 PM

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.

 

 



Sponsor:

#2 Samurai Jack   Members   -  Reputation: 238

Like
0Likes
Like

Posted 12 August 2014 - 01:03 AM

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?



#3 NumberXaero   Prime Members   -  Reputation: 1514

Like
3Likes
Like

Posted 12 August 2014 - 01:49 AM

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


Edited by NumberXaero, 12 August 2014 - 01:51 AM.


#4 CRYP7IK   Members   -  Reputation: 1025

Like
0Likes
Like

Posted 12 August 2014 - 06:34 AM


- 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.


To accomplish great things we must first dream, then visualize, then plan...believe... act! - Alfred A. Montapert
Gold Coast Studio Manager, Lead Programmer and IT Admin at Valhalla Studios Bifrost.

#5 Bregma   Crossbones+   -  Reputation: 5469

Like
0Likes
Like

Posted 12 August 2014 - 07:30 AM


- 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.

Well, yes, you need to set up to use the framework.  It's a one-time dealie and you generally don't have to worry about it again, it's just code and play.  Just like any other framework.


Stephen M. Webb
Professional Free Software Developer

#6 tmason   Members   -  Reputation: 296

Like
0Likes
Like

Posted 12 August 2014 - 02:08 PM

 


- 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.



#7 tmason   Members   -  Reputation: 296

Like
0Likes
Like

Posted 12 August 2014 - 02:26 PM

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?



#8 Bregma   Crossbones+   -  Reputation: 5469

Like
1Likes
Like

Posted 12 August 2014 - 04:21 PM


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. 


Stephen M. Webb
Professional Free Software Developer

#9 tmason   Members   -  Reputation: 296

Like
0Likes
Like

Posted 12 August 2014 - 05:39 PM

 


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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS