GUI Libraries Are Like Art

….Everyone has a differing opinion on them, and often only the most complicated become popular. (Take that opinion with a grain of salt if you will; I sure didn’t think of that comparison very long)

Anyway, so my Dad asked me to make for him a cross-platform GUI-based application that can generate password strings randomly with various customization options and capabilities. I was to use C/C++, and I knew exactly what I wanted to do and how to do it, the only thing I needed to take my time on was the actual GUI. It turns out, this will likely be a bigger task than making the actual program. I thought I had some reasonable experience with wxWidgets. Afterall, I had started working with it for a project of mine and it was going rather smoothly. But then, as I found, doing some of the more advanced stuff is…not on the easy side. The steps involved to getting what I want were proving to be quite long and tedious, and on top of that it would eventually turn your code into a massive, ugly, hard to read mess.

So, I set out to look for some other GUI libraries. Below, I’ll talk about the 3 most popular I’ve found; wxWidgets (as already mentioned), MFC, and Qt.

MFC (Microsoft® Foundation Class)

Every built-in Windows application uses MFC (who’d a thunk it?). Applications designed specifically for Windows will often use MFC (if not C# and the .NET platform, but that’s a different story altogether). This all being said, MFC is not cross platform, making it not suit my requirements right off the bat. However, looking into it, MFC is similar to wxWidgets, and suffers the same convoluted, painful programming design scheme imaginable. I’ll go into more detail on this when I talk of wxWidgets next. Also, another fun fact is that actually, wxWidgets is based off MFC since it came first. Just figure I’d clarify that. 😛


Ah, wxWidgets. Such a neat idea but so, so poorly executed. The one big upside to wxWidgets (or wx as I’ll call it from here on in this blog post) is that it is cross-platform, and has many additional tools to handle things like low-level file input/output, setting up rendering contexts, and even handling tasks like printing to a printer. Neat stuff, but it’s horrendous coding ethic is not so good. Take for instance this idea: To have any component in your application (a button or toolbar, as examples), you must instantiate an instance of the particular wx type for that component, then specify it’s properties through its members. Example:

class Button : public wxButton
	virtual void OnClick();
// Then, in your main program, you'd call something like Button MyButton(size, ID, etc.);

This is fine and all, but in practice is becomes quite a mess. The fact that almost NONE of the other functions refer to each other through pointers or other forms of memory access, and instead rely on an unsigned int “ID” system (which ultimately forces you to write GIANT enum blocks to provide any form of sanity to it), and you have yourself a lot of illegible code and extra typing for very little result. MFC pulls this same garbage, but fortunately MFC will automatically use the ANSI or Unicode versions of their functions if you use a single, simple define (unlike wx which requires you to prefix EVERY. SINGLE. STRING. with a special conversion Macro–which is “_T(<String>)”). Coupled with pretty poor documentation and confusing layouts, and you have wx: a big pain in the behind.


Qt was a relatively new discovery for me. I found this gem while googling around for some information on other GUI libraries. Qt is nice, but has some drawbacks that make me…not want to use it. It is fully Unicode compliant, it is pretty easy to work with, it has a form designer (think the MFC/Visual Basic form designer), it’s fast, and uses a unique idea for running a GUI via a “slot/responder” system (the exact details are a bit sketchy; I’ve only read some basic information about it but it seems pretty effective at preventing errors and remaining typesafe at the least). So what is the catch? Well, for one, the form designer is limited to only the most basic applications (which is somewhat expected, but I think MFC’s designer could at least do some relatively large-scale applications). Qt’s designer also has a different learning curve compared to other form designers (though not nearly as bad the wx form designer…don’t even bother with it). But the biggest thing that turned me away was that the Qt GUI code is spit out in it’s own language! Not straight C++ or anything, but in it’s own proprietary language. Ultimately, the compiler converts the input code into a C++ form, which if what I remember what I read correctly, can be spit into source files for someone to edit, but the thing is that you have to take an extra step just to do so! So essentially you have to design your application entirely in Qt first (either by hand typing the code or by using the form designer), compile it, and then and only then can you make any “tweaks” to it from the Cpp sources. This is unfortunate, because it sounds awesome, but that extra bit of steps just ruins it for me at least.

In Conclusion

So far it seems that there aren’t any feasible, simple GUI libraries that don’t require extra work or overhead to create an application. SO WHAT IS THE SOLUTION TO THAT? You either write your own (good luck with that), OR write a wrapper for an existing one so that it’s NOT as painful to work with. Hence, I’ll likely be writing my own wrapper for wx, since it’s cross-platform and works in native C++, two points it has over MFC and Qt, respectively. I’ll have to figure some way around that God-awful Unicode macro, but I’m sure a solution will be available.

Leave a Reply