Why all GUI toolkits suck?

Pages: 12
After experimenting with various GUI toolkits I came to an impression that all GUI in C++ suck very bad, to name few:

Qt, has most futures but it uses non standard stuff that doesn't look like C++ at all, and you need to use ugly macros and invoke various external tools to make things work.

Gtkmm, this one is probably the most clean "C++" GUI API I seen so far, very easy to learn and easy to work with, but behind the scene there is a big mess, making things work on windows is not for beginers, I spent a whole week to install an old version from source on windows, new version didn't work well due to anormous amount of bugs that you need to "hack" in order to make all work, imposible.

ATL, I like it very much probably because it's completely based on templates so one can do what ever he want's but it's also based on COM, the binary standard, and it's not cross platform.

MFC, honestly I didn't even try to spend my (allready spent) time to learn how to use jet another probably buggy and hard to learn library, all I can say about MFC is that nobody who learned it like it, so why to bother.

GTK+ not C++ library but this one is probably the worst one could choose to learn, the same thing as with gtkmm, they calim it to be cross platfom, yes if you use 10 years old version, then it's probably cross platform.

wxWidgets, I spent only few days learning this one, it looks that nobody maintains the source code, not sure, it has very few features for todays development, so out of discusion.

WINDOWS API, this one is probably your best bet, while it's not GUI tool kit and not cross platform and also not C++ library, however one can do what ever he wants, but today everbody does net programing, and they claim that WIN32 is ooold, and that nobody learns WIN32 anymore, furtermore Microsoft also "abandoned" native API in some way, they are now focusing on .NET, "cloud stuff" and similar stuff which they call a "new technology".

.NET the most clean API but it's not native C++, and you need a virtual machine in order to ran .NET stuff, so out of discusion for C++.


Can somebody convince me that GUI programing in C++ does not suck as much as I think it does?
I came to conclusion that the best thing is to just use Windows API and create your own reusable GUI interfaces and just leave all the stuff that other created, this means one needs also say good bye to linux and MAC, but so what open source suck as well, compiling and installing open source software almost always means fighting with bugs and learing a lot of things in order to make things work.

Just how many questions on the internet you can find, ie. "what GUI to use with C++" recommendations are always x, y, z...
Qt, has most futures but it uses non standard stuff that doesn't look like C++ at all
What exactly doesn't make it look like c++? The Q before the stuff? You don't have to use QString and stuff if you don't want you can use std::string and convert to their type if you wanted to.

Anyways QtDesigner is pretty amazing IMO.
closed account (z05DSL3A)
Can somebody convince me that GUI programing in C++ does not suck as much as I think it does?
By the sound of it; probably not.

@giblit
yes exactly, if you want to make part of some existing code to work with Qt, you need to convert your code or use Qt built in containers, and also it looks that Qt team never heard about namespaces, typing Q every now and then is what some people consider a "bad design" in modern C++, this is what I meant by "non standard" it looks like C.(yes Qt is old)

I know you defend Qt, this is because people defend what they know, that's fine, we all have a freedom to choose what we want, but, I'm talking in general terms not strictly against Qt.

@Grey Wolf
By the sound of it; probably not.

thank you, that sounds honest enough ;)
How about FLTK http://www.fltk.org/index.php I believe I built it on windows once and it wasn't particularly difficult.
closed account (z05DSL3A)
:0)

When it comes to Windows, Windows API and Windows Runtime (WinRT*) are the base level that all the other stuff builds on.

Saying things like Win32 is old is doing it a disservice. I would be like saying your brand new car is old because the internal combustion engine has been around for a hundred years.

There is no easy answer to Windows UI, I'm not even sure Microsoft has a clear idea of where they are going...I'm currently planning a project and trying to decide what is going to be best.

________________________________
* not to be confused with Windows RT
closed account (10X9216C)
typing Q every now and then is what some people consider a "bad design" in modern C++, this is what I meant by "non standard" it looks like C.(yes Qt is old)

Qt has been around for 20 years, i assume that is the reason they don't rewrite the entire library to conform to what's considered modern.

Qt, has most futures but it uses non standard stuff that doesn't look like C++ at all, and you need to use ugly macros and invoke various external tools to make things work.

"Ugly Macros", they have their uses, wxWidgets probably uses it the worst of them all. Try to follow one macro to see what it does, it leads to 10+ more nested macros. It also takes control of main() iirc defining it in a macro somewhere. If you think invoking external tools to do work is a negative, what do you think Visual Studio does for .net's gui? You know how much crap is generated by visual studio that isn't part of standard C#? I also assume you don't use build systems, cause they aren't part of C++... Using QtCreator is indeed the easiest way to use Qt, especially if you don't feel like taking the time to create your own setup.

How about FLTK http://www.fltk.org/index.php I believe I built it on windows once and it wasn't particularly difficult.

I think the only problem with FLTK is how bad it looks, at least the last time i used it.

Awesomium is another library to look at, or chromium embedded. Then you can use html/css to create the gui. Seems to be a growing trend in indie game development at least, can easily be used to make a gui for a program instead.
Last edited on
@myesolar
what do you think Visual Studio does for .net's gui

yes, for sure, visual studio is so good at hidding everything, and thats why it behaves much more clean than any other IDE.

well maybe I misspelled about macros, macros indeed are useful in many situations, what I meant realy is that macros which are visible to the library users are the ones that should not be visible, in other words this would define a library as "clean". good example of this is gtkmm.

I also assume you don't use build systems

actually I'm using my own setup of GNU make, vim and other stuff a lot in linux, also cmake sometimes to port from windows to linux and vice versa, in fact I don't realy understand why some people overuse these macros?, not only that but they are calling them "powerfull!!" lol
I simply can't see anything powerfull, other than excluding the code not related to the operating system.

to demonstrate what I mean, very simple example:
1
2
3
#define PI 3.1415
// use PI
double foo = PI;

i can't see anything powerfull in the above code, and it looks ugly.

can't you just write:
1
2
3
const double PI = 3.1415;
// use PI
double foo = PI;


Yes I know what you're thinking right now, in the first example you'll end up with 50% less memory usage...
but who cares realy?,
it's only 8 bytes and te code looks more clean(of macros)

however following is a different story:
1
2
3
#ifdef _WIN32
#define close(foo) _close (foo) // enables using /sdl checks
#endif 

the above macro is absolutely wanted and there no way to make it more simple than it is using standard c++

another example (Qt again, sorry Qt users, it's just an example)
1
2
3
4
5
6
7
8
class Window : public QWidget
{
     Q_OBJECT  // what the hell is this??

 public:
     Window();
     // ...
};


gtkmm is much better:
1
2
3
4
5
6
7
8
class Window : public Gtk::Widget
{
    // no need for ugly macro

    public:
        mywindow();
   // ...
};


now you understand what I mean by "ugly macros"

naraku9333 mentioned fltk, I don't know, but after seeing the screenshots of user interfaces on fltk's oficial web page http://www.fltk.org/shots.php
it is obvious that FLTK is yet another GUI library which could be added to my list above. I'm sorry man, but just look at these screenshots!
Last edited on
Your expectations are too high. Make your own cross-platform GUI toolkit and tell me how it goes - who knows, if you stick to it we might have something great :)
If what you're going for isn't fluff but usability and portability, I don't see anything wrong with fltk. Rather, that's the whole point. It's minimalist and cross-platform.
@LB
yes, reinventing the wheel is probably the best solution when it cames to GUI in C++, but of course not in terms of creating a whole GUI framework :)
LB's response is actually the normal response.

If you don't like any of the GUIs available then write your own. You will either succeed and make a GUI framework you like, gain an appreciation for the GUIs available and use them for your projects, or go insane over minor details of every projects.


I was told that when I was complaining about the old GUI framework in Allegro.
closed account (10X9216C)
i can't see anything powerfull in the above code, and it looks ugly.

That's exactly what const was made to replace. So it's no wonder you find the latter more useful.

yes, for sure, visual studio is so good at hidding everything, and thats why it behaves much more clean than any other IDE.

That's what all Qt tools are for and why build systems exist.

now you understand what I mean by "ugly macros"

No I don't. Gtk doesn't provide the same functionality as Qt, if you are willing to throw away a useful feature for such a reason, then be my guest. If Gtk had the same feature set, and they didn't use a Macro, it would look even worse. Not to mention the amount of code duplication.
yes exactly, if you want to make part of some existing code to work with Qt, you need to convert your code or use Qt built in containers

For the most part all that means is to add a 'Q' to the start of your types. Creating your own types takes one extra step and requires adding one of the few macros to your code Q_DECLARE_METATYPE and of course adding #include <QMetaType> . I hardly see that as painful since for the most part Qt types are more useful than standard C++ types.

To complain about ugly macros and praise winapi at the same time is beyond my understanding.
Why blame library designers for using macros? Aren't they part of modern C++?
If C++ had powerful metaprogramming capabilities, noone would ever consider old C macros in modern libraries and all those ugly macros would have been rewritten long ago. But there is still no alternative. Templates address only a small subset of what C macros can do, and an extremely tiny subset of what modern macro systems can do.
Last edited on
Since I criticized almost every GUI API on the planet, it's almost normal to expect "downvotes" from everyone...

If I hurt anyone please excuse me, all I wanted to express here is as I said in my first post:
"I came to an impression that all GUI in C++ suck very bad"

this however does not necessarily mean that this is true..

don't get me wrong here, not everything is so black in my view, various people use various tools, it's personal opinion which should be respected, and I respect what ever you use..
So *personaly* I like gtkmm most of all other API's because of few simple reasons:
1. gtkmm fully supports standard library, no need to "abandon" that part.
1. you never need to invoke even a *single* macro!
3. it uses namespaces, so you never have type prefixes before variable.
4. it's compatible with many other libraries, you don't need to convert stuff.
5. it's absolutely free, do what ever you want with (shoot yourself in a foot).
6. if you want to use it with visual studio, no problem, just include the headers and tell the linker where your libs are and you enjoy all the features visual studio provides..

Now please tell me, does any known GUI library provide at least a subset of the above?? I don't think so.. please tell me which is it so I pick it up then, thanks!

@myesolar
Gtk doesn't provide the same functionality as Qt

please tell me about what features exactly are you talking about?
I use gtkmm not Gtk btw which is a C++ binding to Gtk, sorry but I can't see about what features are you talking about, in fact you're right gtk it self does not provide anything else but widgets, but Gtk is not just Gtk there are at least 20 other libraries included with Gtmm, which provide all sorts of features and I can't realy see what features Qt provides that gtkmm and other stuff do not?

@admkrk
To complain about ugly macros and praise winapi at the same time is beyond my understanding

if I have to deal with macros then I'm gonna go down and deal with them where they belong, GUI tollkit is definitely not the right place for macros at least that's one of my expectations from GUI toolkit, that's why I like either gtkmm or just go down and use plain Windows API's and fight with macros, even if that would mean (as BHX said in his post)
go insane over minor details of every projects



closed account (10X9216C)
Since I criticized almost every GUI API on the planet, it's almost normal to expect "downvotes" from everyone...

You completely ignored my suggestions in favor of my comments about Qt, so no not almost every GUI api on the planet.
please tell me about what features exactly are you talking about?
I use gtkmm not Gtk btw which is a C++ binding to Gtk, sorry but I can't see about what features are you talking about, in fact you're right gtk it self does not provide anything else but widgets, but Gtk is not just Gtk there are at least 20 other libraries included with Gtmm, which provide all sorts of features and I can't realy see what features Qt provides that gtkmm and other stuff do not?

Signals/slots that you can connect to, it provides a sort of "reflection" which C++ itself lacks. Go look at the documentation and see what Q_OBJECT defines. Gtkmm is just a library based off of GTK, whatever it does will be capped, in some way, by GTK.

rabidcoder wrote:
Why blame library designers for using macros? Aren't they part of modern C++?
If C++ had powerful metaprogramming capabilities, noone would ever consider old C macros in modern libraries and all those ugly macros would have been rewritten long ago. But there is still no alternative. Templates address only a small subset of what C macros can do, and an extremely tiny subset of what modern macro systems can do.

Oh this one <3. Templates were never meant to completely replace macros. Metaprogramming was an unexpected side effect of the way templates had been implemented. So they weren't really "designed" to do anything. Following the bandwagon again i see, seems you are reluctant to learn, as your C++ map brethren.
Last edited on

Oh this one <3. Templates were never meant to completely replace macros.


Excellent. Yet every "modern" C++ coder would tell you how macros are ugly and shouldn't be used. So what should those poor GUI library designers use? There is no alternative. C macros are still the way to go, in 2014.
From what I researched, the Q_OBJECT macro defines nothing and is just a marker for tools that parse source files.
Pages: 12