Hacker News Reader

Comment by scrollaway | Hacker News Reader

This post was written by Morten Welinder, the author of Gnumeric and a popular GNOME blogger.

I feel really bad for GTK developers. The GNOME guys have clearly taken the toolkit from a "general purpose" direction to a much more gnome-centric one.

At the same time though, I can't help but be hopeful for the future. Qt is a wonderful project, with a bunch of wonderful licenses, developed in a wonderfully-open environment (It's not like before!) and with wonderful improvements already available in Qt 5. With more and more applications switching to it, I see Qt as a central part of the Linux desktop ecosystem in the future - finally, not only will we have a beautiful desktop with common themes for all apps, but also the power of a truly cross-platform toolkit in most Linux apps. It will be nice.

View on HN

I feel really conflicted about Qt. On one hand, as a graphical toolkit/environment, it's great. It's well-structured and easy to use, and QML is basically everything web applications should have been.

On the other hand, as a C++ library it really couldn't be worse, with its flagrant reinvention of the standard library, pervasive UTF16, complex object hierarchies, raw pointers, extensive use of macros, etc., etc.

Maybe I'm just too choosy, but it'd be really nice to have a graphical toolkit that didn't have such an air of sausage factory to it.

I think that the reason for reimplementing stl functionality is that they want complex types such as QString as a part of their external interface and they want different minor versions to be binary compatible which can't be guaranteed for types like std::string unless everything is compiled with the same compiler and runtime. See https://qt-project.org/wiki/Dpointer

As for the raw pointer use you should always use QPointer smart pointers for objects whose lifetime you don't control. However they don't recommend passing QPointers as function parameters since they are easily/cheaply constructed and the reference count is embedded in the QObject instance itself in any case.

I really like the Qt syntax. It's well though out, readable, I can overlook it without years of study and it has a good documentation. I think it helps to not think about it as C++ at all, because it isn't really. It's a syntax subset of C++ with a few extensions and it's own standard library that happens to use a C++ compiler somewhere down the toolchain.

I don't see the issue with the object hierarchies either. You have your QObject and QWidget classes that are important and then all the stuff that builds on that. Not that complicated really once you get into it.

The UTF-16 thing is ugly, yea, but I did never see a practical issue with it.

Totally agree. After studying C++, I was wary of trying to use the language. It seemed to me that you'll get into trouble quickly and it requires years of experience to become an expert. I would rather use Qt because it insulates you from many of the pitfalls of C++. I especially like the slots and signals paradigm. I know there are libraries that do the same thing, but if you stay within the Qt framework, you'll be a lot more productive.

> On the other hand, as a C++ library it really couldn't be worse, with its flagrant reinvention of the standard library, pervasive UTF16, complex object hierarchies, raw pointers, extensive use of macros, etc., etc.

Have you given Qt a serious try? Most of the above arguments don't hold good at all. * c++ std lib is total crap. Anyone arguing for it has no idea what a good API is. Have you used Qt container? It's as intuitive as it gets. The C++ std lib is performance optimized and most desktop apps don't need it. It comes at a cost of developers having to learn complex APIs.

* Complex object hierarchies - huh? Qt's value based types need no memory management. The pointer types has a simple parent-child relationship. Delete the parent and all children are deleted as well. How hard is this?

* Raw pointers - Commented truly like someone who hasn't understood Qt.

* Why do you care about UTF16? It's an internal representation. BTW, Do you write any web apps? Do you know or care what internal representation is used by strings? If you some ultra-special case of a performance critical app, no string library out there will be good for you. You will have to roll out your own.

Let me guess. It really looks like you are one on the few guys who likes writing libraries (as opposed to apps). People who write apps love Qt. People who like writing libraries don't like any other library other than their own because their way is the true way.

There are many valid criticism of Qt but these are none of them.

Calling the C++ standard library crap is acknowledging the Wheel was Not Invented Here.

Glazing over the fact that Qt has an incredibly complicated object hierarchy by saying "they're good for you" is not acknowledging the fact that it's complicated and difficult to learn or work with. You didn't even mention, e.g., MOC - Qt's incredibly complicated Meta-Object Compiler. And people call GObject complicated...

Ignoring the fact that basically every other platform than Windows (and the platforms it has managed to infect) uses UTF-8 as its One True Encoding, and that you and Qt are proliferating the claim that every sufficiently complicated C++ project has its own string class with its own specific peculiarities is not a good thing.

Most importantly, you can't dismiss his concerns by agreeing that all of them exist and that he shouldn't care.

I honestly don't get these arguments.

Not sure how you concluded this is about NIH. Qt's container are very developer friendly and as an application author that's the first and most important thing that matters.

Saying moc is complicated is like saying dalvik or ART is complicated. These are just tools that work in the background. Just like you don't need to know ART internals, you don't need to know moc or the code it generates for you.

Arguing about string encoding is so 1990's, I won't comment.

No offence, but you calling the STL "total crap" can lend others to claim you haven't given the STL a serious try as well. A related stackexchange question on critisms of the STL [1]

[1] http://gamedev.stackexchange.com/questions/268/stl-for-games...

He/she called the std lib total crap, not the STL. A very strong and broad statement though.

> flagrant reinvention of the standard library

That's b/c the C++ standard library (or its implementation among various compilers) was terrible 13 years ago when Qt 3 was released. Some say it still is.

pyqt is the answer

How would people feel about a cleanup-focused API-compatible fork of Qt, in the style of LibReSSL?

It would be stupid and pointless? The Qt Project is an incredibly open environment. You want cleanups, go and file some PRs.

WTF is it with people's first instinct being "let's fork instead of contributing fixes"?

Sorry, "fork" was the wrong term. How about "long-term working branch that might get merged eventually, but also might get used in preference to the original to the point that people start just submitting their PRs directly to it"? (Think egcs's "fork" of gcc.)

And what is the point? You haven't actually suggested any improvements that require such a "fork"

Not everybody likes Qt's CLA.

And by "Not everybody" you of course mean "People who don't know any better", right? The Qt legal situation has changed a lot lately, especially since Nokia went out of the picture. Look it up:

https://qt-project.org/legal.html

The situation is that a CLA is still required. Personally, I don't care (I'm just a consumer who is not affected by the CLA). Others care and insulting them as "People who don't know any better" is not right.

I've always preferred Gtkmm over Qt. That might be because Gtk+ (and Gtkmm) doesn't try to be an "everything, including the kitchen sink" library (and, in related news, I've never been a fan of the Gnome API -- even though I was a fan of the Gnome desktop until Gnome 3).

However, it's always seemed a little perverse to me to have Gtk+ try to imitate '90s-style C++ in C, and then to use a C++ wrapper around that.

> doesn't try to be an "everything, including the kitchen sink"

Qt5 and its modularity is the answer to your concern. If you don't want everything including QtKitchenSink, you can limit yourself to QtCore.

The signals system of Gtkmm seems pretty neat.

I agree, gtk2 was very nice and pleasant to learn, though gnomers have let the other camp to eat their lunch.

Reply on news.ycombinator.com