If you need a short answer: There is no fine solution. I used a lot of gui libraries extensively (in many languages), and the best would be a not too heavyweight widget based library without hacky solutions. There is no really good, clean solution for C++ unfortunatlely.
First, what is a widget based system??? I give this honours only to a gui library that uses object oriented design. Every control every panel, and every window is an object. In optimal case all you do is creating widget objects and setting their properties. Even building a gui hierarchy is just about setting the 'parent' property of the widgets. MFC and its friends are not widget based, and to make things worse, they are built on top of the heritage of low level win32 api solutions like dialog resources, and they are adding their own non-object oriented cr*p to the C winapi. These are so outdated solutions!!! Not to mention that its impossible to make such a program portable!!! (proting dialog resources???) If you are new to gui programming on win32, you have 2 choices. You can learn the the low level winapi + dialog resource stuff, and maybe later you learn MFC that builds on top of that, or you learn building gui with a nice widget based system. Using a well designed widget based system will eliminate a lot of bugs from your program, you will be able to build nicer guis faster, and usually a program based on a widget based system is much easier to make crossplatform, and its easier to change the gui system later. If you don't wanna build heavily size-optimized small executables (4k intro
) and you are not that interested in the gui related winapi, then you dont have to learn it and definately go on with learning about widget based systems.
The C++ gui library that is the nearest to my expectations is Qt, but that library is heavyweight (I'm detailing it below) and uses code generator, its special syntax and its solutions might be very complex for a C++ beginner.
Terrible API, not even fully C++ style (not a widget based one). It has lots of methods which have the same name as the underlying wrapped winapi, but with different parameters. This confused me when I started MFC despite the fact that I was very good at creating gui with winapi. The poor api gives so complex solutions to simple problems (like splitters) that you can't memorize it even after years, you have to search the net and copy paste it right into your code every time. Resizable controls and dialogs need extra effort and helper libraries (you found some on codeproject). The gui you create with this can look nice windows native if you dont use a lot of cheap poorly designed custom controls.
My opinion is nearly the same as about MFC, its a crossplatform MFC with some extra sh*t added to keep the stuff crossplatform. Note that MFC isn't only a pure gui library, its a big application framework that provides a lot of helper classes for other problems too (networking, file management, ...) but I don't recommend getting used to those helpers if you want to create crossplatform code.
The .Net gui builder is nice and widget based. Haven't mixed c++ and .net yet, but iam agains heterogenous systems. One of my friends used .net to create gui for a c++ project and it was a big mistake with regrets. Debugging problems, slow UI, lots of bugs because it takes some time to get used to the common mistakes ppl make when they start using the gate between C++ and cli. Longer learning curve because you have to use 2 languages - the extra learning complexity is true even if you use C++/cli. .Net has very nice UI editor that uses anchoring to provide resizable layout (my favorite general layout mechanism), so this option seems to be an attractive one at first, but it has a lot of drawbacks. Visual basic, .net, and delphi use very similar nice gui building systems. Someone should have made one for c++, but noone started doing it. It would be completely possible by using the same workflow as JFormDesigner for java swing.
Widget based. Has a similar rapid ide as .net and delphi but I never liked its layout mechanisms and the controls that look native on neither operating systems. It has a signal-slot mechanism (a hyped and totally unnecessary feature) to send events between objects (events like button clicking), I never found out why is this better than an event listener, but it at least makes necessary to use a code generator with Qt that I don't like. You write your gui code in c++ and before compilation you have to preprocess it with the qt code generator. I would also mention that Qt contains a lot of other not gui related helper libraries like MFC that make this quite a big bloat and heavy-weight (however this isn't always a problem in a pc program). A nice feature of Qt that some complex controls have data model (like in java swing) that is a big black box for a lot of ppl who haven't worked with modern gui libraries, but if I wrote a gui library I would use data models in every controls.
If you want to understand the underlying C winapi for gui programming, then buy "Buy Programming Windows by Petzold." as Aescleal recommended. Thats the best book to start out with general winapi and GUI programming in C. Its in C and not C++ because most of the basic winapi is pure C without c++ support, so you use it as C even from C++. Even if you use a complete C++ library for some kind of stuff, its good to know the underlying C winapi that you library uses. This will be useful when you want to start writing your own rapid gui development tool for C++.
I should start writing one based on the best practices of Delphi, swing and JFormDesigner, but I just dont want to sacrifice my time for it.
EDIT: My bad, I mentioned JBuilder instead of JFormDesigner.
Added some explanation about widgets. What do I consider a widget?
ANOTHER EDIT: Always forgot to mention C++Builder
, that was the sibling of Delphi from Borland. If I'm right that product is still in development. It is driven by exactly the same IDE and gui library as Delphi! We just stopped using it because of its custom C++ compiler (we preferred VC++) that had crash bugs. We also had some problems with compiling some crossplatform libraries but that was a minor headache. Maybe they have fixed those bugs already. I'm not using it because I'm a VC++ fun (most libraries support this compiler) and because C++Builder is not crossplatform (at least it wasnt when I used it). Still, if you want to know what I mean on gui development definately check out either Delphi(objectpascal) or C++Builder!!! What I didn't like in Delphi that it had no typesafe containers (they already introduced generics) and another stuff I miss from the gui is that they should have a data model, at least in the complex controls (listview, tree, ...). The custom compiler is needed because of the built in gui serialization support and some other fancy stuff - like the object method pointers (delegates) that are used to handle gui events.
Another problem is that I don't know if you can use it for free currently. But if pricing isn't a problem and you can stick to windows and the compiler of C++Builder, then this is definately a very-very nice development and gui building environment on windows!!!!!!! Especially if you are writing database handling applications because it also has components and table controls that support that!