Why all GUI toolkits suck?

Pages: 12
I think codekiddy is being reasonable.

I also think, however, that if he were to see his vision of a perfect GUI framework, it would require a bit of extra work from the user. I don't think a little extra work is much of a price.
IWishIKnew wrote:
I also think, however, that if he were to see his vision of a perfect GUI framework, it would require a bit of extra work from the user. I don't think a little extra work is much of a price.

Problem with that is that I see more and more programmers wanting to get more done with less work and fewer lines of code written.
Yeah... I'd be willing to write some extra code if it meant a cleaner library.

I suppose I don't speak for everyone, though.
@LB
I followed the Q_OBJECT macro in the Qt source code, and this is what I got:
1
2
3
4
5
6
7
8
9
10
11
#define Q_OBJECT \
public: \
    Q_OBJECT_CHECK \
    static const QMetaObject staticMetaObject; \
    virtual const QMetaObject *metaObject() const; \
    virtual void *qt_metacast(const char *); \
    QT_TR_FUNCTIONS \
    virtual int qt_metacall(QMetaObject::Call, int, void **); \
private: \
    Q_DECL_HIDDEN_STATIC_METACALL static void qt_static_metacall(QObject *, QMetaObject::Call, int, void **); \
    struct QPrivateSignal {}; 


@codekiddy
What do you mean you can't use the standard library with Qt? Of course you can! Most people don't, due to a number of reasons such as keeping everything 'Qt'-like or apparently poor implementations on some platforms, but the option is there. Most of the Qt classes even provide options for converting to their standard counterparts, I'm pretty sure, like with QString::toStdString().

As for macros, yes, they might be ugly, but in some cases the best option is to use them. As a well known example, the Boost library provides a number of functions with macros, especially in libraries like Boost.Python - the BOOST_FOREACH macro (though now deprecated) was also particularly well known. I'm not against macros if they simplify my code.
What do you mean you can't use the standard library with Qt? Of course you can!


what I mean is for example this scenario:

1
2
3
4
void f(std::string str)
{
       QLabel MyLabel(str); // not likely to work
}


the above function looks so nice but it doesn't work because you must do string conversion in order to create a label.

QString::toStdString().
what if there is some external or existing code you wish to import into your application?

you'll need to convert everything into 'Q-like' as you say :)

I don't like that because it forces me to do extra work and also forces me to learn new stuff not related to creating widgets, and also forces me to not use what I want but what 'Qt' want, thanks Qt but maybe tomorow.

please note it's not about QString vs std::string, QString may be even better than std::string, and there may probably be other Qt stuff better than std stuff, but what's the purpose of learning something you already know?
what the purpose of hawing a knowelege of both QString and string?
this just an example with string vs QString but you'll see what I mean when it comes to 3D...

I will again compare Qt with gtkmm which does the same stuff but gives the programer more freedom:

1
2
3
4
void f(std::string str)
{
       Gtk::Label MyLabel(str); // no problem
}


but the option is there.

I agree, there is an option but I dislike such additional options, mainly because all that involes extra learing and 0 purpose, sorry.

however, the fact that gtkmm works with standard containers does not make it "must have" library, because one day if you want to do 3D stuff then you have very limited options with both Qt and gtkmm because you'll have to use openGL, this is probably OK if you like or need OpenGL, but what if you don't?
what if you want to use DirecX?
obviously then you'll came to the same conclusion as I did, which is that GUI toolkits suck very bad because it will eat your time once again! :)
very sad truth but so it is.

Note to the users who look for some GUI toolkit.
You can agree with me or not but more you use some GUI toolkit more deep into the sheet you go because soon or later you'll need to learn something you already know thus loosing time and reinventing the whell instead of learning new stuff.

learning is expensive task and should be IMO considered in detail.
Last edited on
I don't like that because it forces me to do extra work and also forces me to learn new stuff not related to creating widgets, and also forces me to not use what I want but what 'Qt' want, thanks Qt but maybe tomorow.

please note it's not about QString vs std::string, QString may be even better than std::string, and there may probably be other Qt stuff better than std stuff, but what's the purpose of learning something you already know?
what the purpose of hawing a knowelege of both QString and string?
Using your argument, one could also conclude the same thing about the C++ standard library. What's the point of learning std::string when you already know C style strings? Why bother, when you can just use arrays everywhere, which are accepted by absolutely everything, with zero conversion?

what if you want to use DirecX?
obviously then you'll came to the same conclusion as I did, which is that GUI toolkits suck very bad because it will eat your time once again!
I don't think any software meets the absurdly high standards you're setting. That is, of supporting everything that has ever been developed that's in some way connected to the nature of the project.
And even if Qt did support DirectX, I'm sure you'd be complaining about bloat and unnecessary features.
I'm pretty sure Qt and DirectX can be used together although I'm not entirely sure why you'd want that. I know Gtk has a Canvas widget that OpenGL and (presumably) DirectX can draw to, Qt most likely has an equivalent. It may not be built in, but why should it?
Last edited on
I'm pretty sure Qt and DirectX can be used together

they can but there are limitations, if you just type "directx" and "Qt" into google you'll allready see people complaining about limitations.

Gtk has a Canvas widget that OpenGL and (presumably) DirectX can draw to

gtkmm uses Goocanvamm::Canvas and Gtk::DrawingArea, I wouldn't recommend anyone even trying to learn using goocanvas, I couldn't even implent to drag and drop things from one widget to canvas with that thing, and the only way to deal with that was to uninstal it and create my own and just use cairo functions for drawing.

there are allways some limitations or even bugs with toolkits and I don't like that fact, but that's probably something we have to eath.

@helios
I don't think any software meets the absurdly high standards you're setting

No it probably doesn't, that's why I think is not worth to deal with toolkits, except for simple projects to create a window and put few buttons on it, sonner or later toolkits impose some limitations and then you stuck together with toolkit.
I think is not worth to deal with toolkits, except for simple projects to create a window and put few buttons on it
Someone should let all those people who are successfully using GUI toolkits know that they're doing it wrong.

sonner or later toolkits impose some limitations and then you stuck together with toolkit.
Having to use one hardware graphics library instead of another is not a limitation.
If you get to a point where a toolkit doesn't provide the functionality you need, the worst case scenario is that you'll have to implement it yourself. You're still better off sticking with the toolkit than writing your own stuff from scratch every time.
Last edited on
No it probably doesn't, that's why I think is not worth to deal with toolkits, except for simple projects to create a window and put few buttons on it, sonner or later toolkits impose some limitations and then you stuck together with toolkit.


And how do you style all the buttons and windows and other widgets in all these toolkits, even with simple projects? With Qt its as simple as adding a css file. Oh wait, make that qss although the syntax is the same you still have to go to the trouble of changing the c to a q.
I've noticed some applications don't even bother with GUIs and just display a webpage to you. You can do whatever you want then ;p
That seems to be the current trend, at least in my area.
I loved to use Borland\embarcadero C++ Builder back in the day. VCL (Virtual Component Library) is really powerful and fun to use.
It's 2014, why aren't we all building our GUIs with HTML?
Because you can't easily overlay HTML with your game as background?
closed account (10X9216C)
Yes you can... It's just an image, you draw it on the screen like everything else.

Overgrowth - http://www.wolfire.com/overgrowth
Stonehearth - http://stonehearth.net/
Garry's mod - http://www.garrysmod.com/

Just to name a few that use html, i'm sure there's plenty more out there.
Last edited on
myesolar wrote:
Yes you can... It's just an image, you draw it on the screen like everything else.
I mean with alpha-transparency, like you can see through the background of the page.
Last edited on
Because you can't easily overlay HTML with your game as background?

I mean with alpha-transparency, like you can see through the background of the page.

What do you mean? You can do this, if I am interpreting you right.
Really? I guess it depends on which library you use, the two I tried didn't seem to have a way to do it.
closed account (10X9216C)
I mean with alpha-transparency, like you can see through the background of the page.

Yes all 3 of those have alpha transparency.

The two api i tested allowed for it. Which ones did you use?
Last edited on
Topic archived. No new replies allowed.
Pages: 12