Wxwidgets


RotsiserMho

Still Fresh
Joined
Nov 5, 2009
Messages
23
So I've looked around the forums a bit and it seems that the consensus among some of the experienced developers is that wxWidgets sucks. However, it was the tool I used to learn a LOT about C++ and GUI programming.

I love the fact that there's a function for pretty much every thing I need (but I can still opt not to link in all the cruft!) and that widgets take on the the look and feel of the native platform. In my mind, this is the epitome of good GUI design. But I'm open to new outlooks on life and learning more about other options. That and I still consider myself a n00b and would like to avoid any wxPitfalls.

That being said, I'm very curious as to why so many dislike it, or at least favor Qt over it so much.
 
Because Qt also has options to exclude unnecessary things, also uses native widgets whenever possible, and also has a function for pretty much everything. So I don't think there's a clear wx advantage on any of those.

Qt has better advertising since they have a lot of graphics demos and since Nokia is working on it now.
Also, Qt has Qt Creator, which is a hell of a lot like Visual Basic. You can just throw GUIs together like Lego bricks. I don't know if WxWidgets has an IDE that can match Creator.

I can't say wxWidgets sucks as I've never used it, but from what I've done with Qt, I can say that Qt is amazing. I also tried GTK+ once and thought it was very inconvenient. If you absolutely must use C, I guess it's a necessity, but C++ / Qt seems to be a lot better.

Edit: What does wxWidgets have for media? GTK+ has GStreamer (complicated as hell but usable) and Qt has Phonon (super-simple, but the old version would crash in some cases, and less featureful than GST).
 
Rotsiser Mho said:
So I've looked around the forums a bit and it seems that the consensus among some of the experienced developers is that wxWidgets sucks. However, it was the tool I used to learn a LOT about C++ and GUI programming.

I love the fact that there's a function for pretty much every thing I need (but I can still opt not to link in all the cruft!) and that widgets take on the the look and feel of the native platform. In my mind, this is the epitome of good GUI design. But I'm open to new outlooks on life and learning more about other options. That and I still consider myself a n00b and would like to avoid any wxPitfalls.

That being said, I'm very curious as to why so many dislike it, or at least favor Qt over it so much.
Because the wxWidgets system *is* badly designed in most people's opinions. It doesn't use many modern C++ features, Bakefiles are ugly, you cannot interact with your GUI except for the very surface, etc.

WX does also not support the same number of features that e.g. Qt does. OK, if you only need a couple of buttons and text boxes, both will suffice. But Qt, with its Signals/Slots system, much richer library and broader API coverage does so much more.

E.g.:
  • If you want to draw to bitmaps or make your own widgets in WX, it's incredibly difficult. Only a bare minimum of operations are supported. Qt, on the other hand, does not only support painting *anywhere* on a window that you own; it also has a complete paint engine built-in which uses e.g. OpenGL, Clutter, Cairo etc as its backend to make the drawing as fast as possible. This means that Qt often is much faster at drawing widgets than the native system is!
  • Qt also offers much more fine-grained control of drawing. Sure, you can draw fonts in WX, but can you control anything beyond the size, face and style? Can you use ligatures, apply effects such as outline rendering, sub-pixel antialiasing (on ALL platforms!), apply matrix transformations to rotate text, draw with gradients, outlines, lines with float-widths, use scalable vector graphics, render web pages/HTML, apply CSS styles to your GUI itself, etc? Heck, something as basic as making part of the text on a button italic in WX is difficult!
  • Want to interact with the operating system through more than the UI? In WX, this is possible to some extent, but you have to do a lot of plumbing to get it to work, and WX doesn't support that many APIs. Qt, on the other hand, has cross-platform APIs that integrate well with all operating systems. I can simply say "connect(fileWatcher, SIGNAL(fileChanged(QString)), this, SLOT(reloadFile(QString)))" to reload a file from disk every time it is changed by another program. Qt will use INotify automatically on Linux to make the Kernel tell the program when the file changes. How can you do this in WX? Take a look at what APIs Qt supports: http://doc.trolltech.com/4.6/overviews.html
  • Qt offers many different ways of making GUIs. You can hard-code your GUI in pure C++, or you can use a designer that generates a *.ui file for you, or you can use QML to set up an UI, or you can use a web page instead of a window, etc... There are so many possibilities.
  • Qt is available through many languages and APIs. You can program in Python, C++, Java, Ruby, JavaScript, QML, you name it. Gives a developer a lot of freedom...

I haven't got time to elaborate any more, but I hope that you at least got an idea of what the differences are.
 
Last edited by a moderator:
Wow, I didn't know Qt had file-watching. I may have to look into this.

Also, yes, Qt has an entire graphics subsystem. Remember how I made that prototype of a game in Qt?
http://blip.tv/file/3164093

And this that someone else made:
http://www.youtube.com/watch?v=MXS3xKV-UM0

Also, the WebKit thing is demonstrated in there. Any Qt application can embed a web browser that is functionally similar to Arora and Midori.
 
I used wxWidgets on Linux once and it just sucked. Native design my ass, it was using it's own implementations all over the place, e.g. for TreeViews. Also it crashed frequently when using the system tray while on Windows it worked fine. In the end I used PyGtk + Glade which was great.
 
EDIT: Aw shucks, guess I should click every link. An enthusiastic second vote for this as a demonstration of Qt's awesomeness:

WolfenQt (judging from what the author said, it's just a proof of concept hack thrown together in a hurry, but it looks pretty sweet to me).

The highlight of that page perhaps being the youtube vid:
http://www.youtube.com/watch?v=MXS3xKV-UM0

At last, an opportunity for inexperienced game engine developers to give Doom 3 in-game-GUIs a run for their money.
 
Last edited by a moderator:
TH0RN5 said:
WolfenQt (judging from what the author said, it's just a proof of concept hack thrown together in a hurry, but it looks pretty sweet to me).

The highlight of that page perhaps being the youtube vid:
http://www.youtube.com/watch?v=MXS3xKV-UM0

At last, an opportunity for inexperienced game engine developers to give Doom 3 in-game-GUIs a run for their money.
Dude, look 2 posts above you...
 
Last edited by a moderator:
TH0RN5 said:
Oh yeah, the writeup of that video.
TH0RN5 said:
At last, an opportunity for inexperienced game engine developers to give Doom 3 in-game-GUIs a run for their money.
Hopefully. All my 3D stuff uses SDL / OpenGL, and I'm not sure how to port it to Qt and get some awesome GUIs going on.
 
Last edited by a moderator:
lulzfish said:
TH0RN5 said:
Oh yeah, the writeup of that video.
TH0RN5 said:
At last, an opportunity for inexperienced game engine developers to give Doom 3 in-game-GUIs a run for their money.
Hopefully. All my 3D stuff uses SDL / OpenGL, and I'm not sure how to port it to Qt and get some awesome GUIs going on.
Extend QGLWidget, override "initializeGL()", "resizeGL()" and "paintGL()" with your custom code (you don't have to create a viewport or anything; just start issuing GL-calls e.g. glClearColor in initializeGL) and you're done. The widget can be used like any other, or as the main widget for the application in which case it can go fullscreen etc.
 
Last edited by a moderator:
lulzfish said:
Wow, I didn't know Qt had file-watching. I may have to look into this.
QFileSystemWatcher ? yeah it has. QFileSystemModel (replace QDirModel) uses it for watching root index so your views on the same "root" directory can be updated if a change happens.
 
Last edited by a moderator:
I'd be interested to hear people's opinions on fltk... I've never done any GUI programming in Linux but have looked into it several times and thought fltk seemed a good choice. I can't stand bloat and inefficiency in software even if it is easy as pie to code, especially in embedded devices, so I'm not really drawn to gtk or qt. fltk seems to have a good middle ground in that it has quite a nice API and is very quick, even if it can only cope with drawing windows and widgets and not all the stuff qt and gtk do, and it is also quite pretty enough (at least with the aqua theme).

On the other hand, I recently did a project at work and decided to use C# .net 3.0 WPF just because I had a very close deadline, and I have to say the API is beautiful compared to win32 C or MFC C++ (not hard), and I really love the vector graphics features, just being able to apply transforms to widgets etc and the xml and databinding features (though databinding can be a pain). I can probably find things like good xml libraries though, and databinding isn't really important. Does anyone know how mature fltk cairo support is? I heard talk of them using AGG instead.

I wish there was something out there as good as the beos/haiku API.

Thoughts?

Edit: oh yeah, there's the whole fltk 1/2/3 thing as well... anyone got opinions on that?
 
OK, not much time, but anyways:
EdCa22 said:
I'd be interested to hear people's opinions on fltk... I've never done any GUI programming in Linux but have looked into it several times and thought fltk seemed a good choice. I can't stand bloat and inefficiency in software even if it is easy as pie to code, especially in embedded devices, so I'm not really drawn to gtk or qt. fltk seems to have a good middle ground in that it has quite a nice API and is very quick, even if it can only cope with drawing windows and widgets and not all the stuff qt and gtk do, and it is also quite pretty enough (at least with the aqua theme).
If you want zero bloat, use the EFL (Enlightenment Foundation Libraries)...
I don't really like bloat either, but I also don't like frameworks that aren't built to be used universally. EFL *is* built to be universally used and supports lots of modern features...
EdCa22 said:
On the other hand, I recently did a project at work and decided to use C# .net 3.0 WPF just because I had a very close deadline, and I have to say the API is beautiful compared to win32 C or MFC C++ (not hard), and I really love the vector graphics features, just being able to apply transforms to widgets etc and the xml and databinding features (though databinding can be a pain). I can probably find things like good xml libraries though, and databinding isn't really important. Does anyone know how mature fltk cairo support is? I heard talk of them using AGG instead.
A FLTK Cairo frontend? Seems to be a trange combination to me; I'd use Qt QML or (more lightweight:) Clutter.

EdCa22 said:
I wish there was something out there as good as the beos/haiku API.
Oh yes, we all have dreams about something...
EdCa22 said:
Edit: oh yeah, there's the whole fltk 1/2/3 thing as well... anyone got opinions on that?
Nah.
 
Last edited by a moderator:
dflemstr said:
If you want zero bloat, use the EFL (Enlightenment Foundation Libraries)...
I don't really like bloat either, but I also don't like frameworks that aren't built to be used universally. EFL *is* built to be universally used and supports lots of modern features...

I'll take a look. Last time I used enlightenment it was too fancy to run on my Pentium 90 laptop (which wasn't all that old at the time). I didn't realise they had a fully fledged toolkit.
Though fltk does run on windows it doesn't fit in, but in this case I really don't care if the program is even OS portable at all.

dflemstr said:
A FLTK Cairo frontend? Seems to be a trange combination to me; I'd use Qt QML or (more lightweight:) Clutter.

Yeah, it can render through cairo apparently. If they want to modernise fltk rendering capabilities it makes sense.... you mean you'd prefer qt+qml or clutter to fltk+cairo?
 
Last edited by a moderator:
EdCa22 said:
you mean you'd prefer qt+qml or clutter to fltk+cairo?
Yes, if it is the extra *flexibility* that you need. If you want to use Cairo "just because" then do so, or if it's the extra performance you need...
 
Last edited by a moderator:
EdCa22 said:
I can't stand bloat and inefficiency in software even if it is easy as pie to code, especially in embedded devices, so I'm not really drawn to gtk or qt. fltk seems to have a good middle ground

This isn't really good thinking.

Gtk and Qt are pretty much the defacto widget sets, and they will come preinstalled on the pandora, and most likely they will be already loaded into memory when the system starts. If you choose some obscure toolkit, you're actually introducing bloat because:

1) You need to bundle the toolkit libraries (waste of space)
2) You are have to load the library into memory when GTK and/or Qt is already loaded there (remember, Linux is big on shared memory)

And considering that CPU is should not the limiting factor (unless you're writing a game, in which case you should just be using SDL or GL or the like), using some small widget toolkit is more like a solution in search of a problem.
 
Last edited by a moderator:
Since the Pandora will be using XFCE I would guess that only Gtk+ will be already loaded into memory when the system starts.
 
Alec  said:
EdCa22 said:
I can't stand bloat and inefficiency in software even if it is easy as pie to code, especially in embedded devices, so I'm not really drawn to gtk or qt. fltk seems to have a good middle ground

This isn't really good thinking.

Gtk and Qt are pretty much the defacto widget sets, and they will come preinstalled on the pandora, and most likely they will be already loaded into memory when the system starts. If you choose some obscure toolkit, you're actually introducing bloat because:

1) You need to bundle the toolkit libraries (waste of space)
2) You are have to load the library into memory when GTK and/or Qt is already loaded there (remember, Linux is big on shared memory)

And considering that CPU is should not the limiting factor (unless you're writing a game, in which case you should just be using SDL or GL or the like), using some small widget toolkit is more like a solution in search of a problem.

No, not at all. I will not be using XFCE and will chose my other applications carefully... I will be customising my install quite significantly, including not choosing gtk or qt applications unless I can find no alternative. So I am discussing the relative pros and cons of toolkits on embedded devices generally, not of toolkits to co-exist with the current application suite on the Pandora.
 
Last edited by a moderator:
Back
Top