Hacker News new | past | comments | ask | show | jobs | submit login

This state of Gtk sad, but I'm really glad we (VLC) moved to Qt, a few years ago (2006), before many applications did the switch, and when it was an unpopular move.

Before that time, we were using WxWidgets and had many issues, notably with Unicode and Windows support. WxWidget APIs and behaviors were changing too much between releases (even minor ones).

When we moved, we were in the early Qt 4.1/4.2 days, and most VLC developers were using Gnome and pushed a lot for Gtk. But one developer started the new UI in Qt, and I picked up the work. We had an important backlash from users, notably with some people in the community recoding an interface in Gtk...

Afterwards, QGtkStyle was introduced, and people could have a native look, even with Gtk environments.

Finally, Qt moved to a community project, to LGPL and Gtk went down the road with Gtk 3.x, breaking themes, Windows, OSX, and API/behaviors at every release (and removing features).

Those days, every cross-platform application are moving to Qt (subsurface, LXDE, wireshark, audacity). It's funny that we made this decision, at that time, without knowing all that. I think we just got very lucky... :D

Around that time I worked for Trolltech and got a good view of how that project was run. The trolls took compatibility very seriously. From devs that were running KDE 3 using the current nightly build of Qt 3 to swapping out the Qt library of various Qt applications with the next Qt release to find any regressions ourselves, keeping things working was important. Dogfooding with KDE, internal tools etc was expected by developers. It is not to say we didn't make mistakes, but we did try to prevent as much as we could. A good API really goes hand in hand with compatibility. Because almost any API change in C++ is incompatible and because any public API we would be stuck with for years there was a huge incentive to get it right. When designing any new API there was always multiple rounds of API design sessions often with many different developers providing feedback and always feedback from the documentation team. Is this API extensible? Does it use the same terminology as the rest of Qt? Could any of the function names be named better? Is there any api missing or that could be removed, etc. New classes had examples and demos not just for documentation purposes, but often enough written first to help find the best API (before actually implementing it) and second to be used to regression test compatibility. Before a release all new API was reviewed one last time to catch any errors that might have slipped through. Many of the lessons learned can be found in "The Little Manual of API design" that was written by one of the Tolls Jasmin Blanchette http://www4.in.tum.de/~blanchet/api-design.pdf It is because of all of this effort that when you are using classes in Qt you often can intuitively know what how the api would work. Again we did make mistakes, but we tried to learn from them and we were not shy about holding back on an API that wasn't ready for a release rather than commit to an API that we were not sure about. I recall more than one API being delayed for the better 6 months or so before being included in the next release (4.3 v.s. 4.2 for example). The result was always a better API and a more bug free class, a win all around.

Nice, but they didn't follow their advice in the case of creating parent-less widgets up to Qt4.

I.e. in Qt3 and previous versions, creating a parent-less widget resulted in a window frame being created. Why was that? If I am creating a button I do not want a window frame around it. I am going to insert the button to another widget later.

Thank God they fixed that in Qt4 and later versions.

Thanks for linking to that PDF! Very interesting read!

Speaking from a Windows user perspective, Qt interfaces feel near-native, much unlike Gtk interfaces, where many of the little details don't quite match native behavior.

But there is this massively annoying little bug where submenus close immediately when you hover another top menu item before reaching the submenu. This makes quickly navigating menus quite cumbersome. (Doesn't happen with native Windows interfaces.)

Does anybody know if the Qt devs are aware of this? Don't they think of it as an issue?

Am I correct thinking you are talking about this bug? https://bugreports.qt-project.org/browse/QTBUG-20094

If so, then yes they are aware of it and treating it as critical.

Edit: Reading into this bug is so cool. This video was linked from it, fascinating stuff: https://www.youtube.com/watch?v=90NsjKvz9Ns&t=18m46s

Exactly, yes! Thank you! This really is fascinating. So the problem is fundamentally solved since 1986. Let's hope Qt will follow soon! :)

I remember when Gtk 2.0 came out. IIRC, at the time, Qt seemed to be bloated and slow compared to Gtk, but Gtk had a lot of breaking changes and was more work to program with. I was unimpressed with having to constantly figure out how to update my Gentoo system when Gtk kept moving functions from one library to another, which required hacking in symlinks to point to new libraries that programs required. It was a real pain in the ass and I finally moved onto Ubuntu. Gentoo had its own probs, but Gtk didn't help.

Er, what? I ran Gentoo from 2001 until mid-2013, and I was a maintainer and core developer of parts of Xfce (a Gtk-based desktop environment) from early 2004 until late 2009, and I have no idea what you're talking about.

Gtk was a pain to develop with, sure, but only due to the awkwardness of GObject's attempts to build an OO system on top of C.

From a user perspective, I never saw the problems you're describing. Even having built Xfce out-of-tree all the time, I never recall having to do a full rebuild due to a Gtk update.

I've since moved on; it's a shame to hear what the OP is saying about 3.x, but 2.x most certainly didn't have these problems that you describe.

I'm talking about the change from Gtk1.0 to Gtk2.0 (or that's what I remember mostly). I gave up on Gentoo around 2001 or so. Things were better when I left, but there was still breakage whenever I did a world-update. I had fallen into the lazy habit of not updating often enough which contributed to the problem, but still, the promise was that all you had to do was to do a world-update and everything would work fine. Maybe it does now, but I remember having to run a crippled system for a couple of weeks at a time, while trying to sort through the numerous broken packages. I had used many different desktops including XFCE. They were all pretty good and completely flexible under Gentoo, as the Desktop designers had intended. That part was fine, but the underlying Gtk libraries were a complete PITA whenever there were large changes.

I'm still a bit confused. The 1.x to 2.x transition was intended to be a breaking change (hence the major version bump). I don't see how you had application issues during that, as 1.x and 2.x were parallel-installable, and apps had to make a conscious decision to upgrade.

I don't recall the stability of the 2.0.x series, though: it's possible they didn't get things right and were still making breaking changes even though it was the stable series. I don't remember that being a problem, but I'll admit my memory of that period isn't perfect.

I do remember some app developers prematurely upgrading and releasing versions that depended on early development releases of 2.0 (and later, on the 2.1.x unstable series), which often did cause breakages. But that was really the app developer's fault for depending on versions that made no API/ABI guarantees.

Sorry, I don't recall the particulars since it was a long time ago. But believe me, there were lots of problems with the libraries. I still cringe whenever I have to deal with a Gtk library.

Both Gentoo and GTK2 were released in 2002.

What distro/OS are you using now, might I ask?

I hope someone revives Firefox's Qt port. Jolla seems to have made progress there but not sure it's enough to have the XUL based interface.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact