The open source wxWidgets library makes programming GUIs incredibly easy, far easier than with most platform APIs. Jeff Cogswell shows how this handy C++ library can shorten your programming time with powerful classes that are simple to use.
Programming C++ GUIs with the wxWidgets Library
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
It’s a good book and the entire thing can be dowloaded from http://www.phptr.com/bookstore/product.asp?isbn=0131473816&rl=1
Tried last year to work with wxWidget (with wx-c on Windows) and it wasn’t too bad, but one thing annoyed me so much I instantly stopped using it:
While resizing a main window the statusbar is not constantly hold in place at the bottom, but jumps to 0,0 for a fraction of a second which means the toolbar flickers.
You may think after so many years they should have done it right…
I’ve worked with wxWidgets for the past 3 years. I’ve never encourtered that problems. Not to say it doens’t exist. There are tons of places you can get assistance with issues like this: mailing list wxforum on shadonet, etc.. All GUI packages are going to have their nuances. Especially with the sizers and messaging in WX. I wouldn’t write it off because of a flickering issue – especially when there are apps out there that work correctly. Someone must know the right way to do it.
is there some IDE or graphical design tool to create wxwidget GUI elements?
and how about “the others” like QT (KDE) becoming available on all platforms.
Yes, there are serveral – here’s two:
DialogBlocks is a commercially available one, you can download a 30 day trial of it. Just google for it.
wxDevCPP – this is the DevCPP from Bloodshed software tied to a Delphi style interface that backends into wx.
If you google for wxDevCPP you should be able to find it. If you remember C++ Builder – this is almost like the wx version of it – although not quite that polished.
I’ve used both and continue to use both for their stengths/weaknesses. DialogBlocks has a fair amount of learning to be done.
In addition to what has been suggested, you should also check out wxDesigner and wxGlade (this is free).
well don’t extect wx to be nearly as well supported as QT is. Yes there are IDEs for it ( if you can call them that) but everything that I have seen so far does the UI in a separate program and from there on you are left patching things up more or less manually. QT has a VS prugin and wting apps with QT or MS gui libraries has very much the same feel. You do everything inside VS ( it does support v.2005 ). But you do have to pay for QT if you want the VS integration or want to write closed source software. ( it isn’t cheap ) As far as capabilities go, QT is more powerful and I personally like it better. But it’s very much a personal choise and it also ties into how much you (your company) are willing to pay for dev tools.
As far as I know there is a commercial Wx plugin for VS, too. I can’t readily give a link however.
There is also VisualWx with support for C++, Python, Perl and Lua
Again a wxWidgets tutorial without an example for signals like GTK/Qt are using.
I once found a tiny example on wxwidgets’ website, but any larger tutorial seems to use the ancient event macro tables.
Is the signal implementation in wxWidgets broken or are the developers stuck in their MFC style programming knowledge?
Don’t forget wxPython http://www.wxpython.org/
It’s the “official” Python bindings for wxWidgets and it is a very mature project at this time. There’s even a book about this versatile combination.
I think it is hard to find a better combination for rapid GUI development than wxWidgets and Python. It is a much better experience than Tkinter and you get native looking and feeling apps to boot!
There’s also bindings for other popular languages such as Perl, Ruby, Lua, C#, and even Java. I don’t know how actively maintained some of these bindings are, however.
Ruby has wxRuby, which is active, but version 2 is still in alpha: http://rubyforge.org/projects/wxruby/.
I also was fascinated by wxWidgets and tried it out for a project. Problem is, it has issues.
For example (all tried with wxGTK):
* If you place a GL widget into a sizer object, on resize it doesn’t always redraw the whole space (but in-scene, the new coordinates are used)
* The wxListBox (or sth) object draws like shit
* Although the native GTK color selector supports an alpha field, it is not supported under wx, so you can’t choose RGBA colors
Overall, I received the impression that whereas WX probably is fine under Windows, it still has issues and inconsistencies all over the place on GTK. Sad, as I very much liked the cross platform idea (esp. the native toolkit approach), but having too many shortcomings renders this useless.
GTK has design elements that make it hard to bind something like wx ontop of it. I’ve had to punt on a few ports to Linux because of it. Overall, it doesn’t sound like many people are pleased with either GTK or Mac ports.
wx is simply elegent to use, has a straight forward API naming convention and is a joy to code with
If you know MFC going over to wx is a breeze – and adds tons of features not found in MFC.
It does a very good job at easing cross-platform development – and with source code out there, if a feature does have a bug ( and ALOT of wx is now very mature code ) then feel free to submit them patches and bug reports.
I have also found the guys on the freenode.net #wxwidgets forum to be very polite and helpfull.
Overall, I love wx and use it pretty much exclusively for my GUI work.
wx is simply elegent to use, has a straight forward API naming convention and is a joy to code with
I’m sure not what toolkit you’re using, but it sure can’t be wxWidgets.
The API naming conventions aren’t at all consistant. I did some work a few months ago improving pgAdmin, and found wxWidgets a real pain to work with. I rewrote the query results display to use a grid instead of a list. Two very similar controls, fairly similar API design, but completely different naming conventions. GetNumberCols vs GetColumnCount, SetColSize vs SetColumnWidth, etc. It’s a pain to use, considering you can’t guess what a method will be called.
Then there’s the issue of why would you want to subject yourself to MFC style coding if you have a choice… MFC has got to be the worst toolkit ever made, yet these people chose to emulate it, ugh.
Then there’s the issue of why would you want to subject yourself to MFC style coding if you have a choice.
WxWidgets used to be WxWindows, that’s why.
I used it in the early 90’s and its API was very weird for the Motif/X Window developer I was then.
I guess choosing MFC style API opened the library to a wider audience.
WxWidgets is not a very good GUI toolkit, because it uses MFC logic (i.e. message maps). Qt is the best, and much much better than WxWidgets.