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.
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?
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.
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.
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'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.
There is a lot about GTK I like; it's a C library making compatibility easier[1], it always seemed way faster (less memory bloat?) than QT, and while the widget-packing/nesting style was somewhat ugly, I found it surprisingly easy to write.
I was even enjoying Vala. While it was obviously a young language, it had a lot of interesting ideas.
Then we got the new 3.x version of GTK with its "lets rewrite everything for no other reason than to break compatibility"[2] project goal that seems to have corrupted far too many projects recently. In addition to the problems already mentioned in this thread, it seemed so.. unfinished. Various components or features were gone or rewritten into something else. I guess they spent all their development time trying to tie Gnome and in as tightly as possible instead of finishing features.
The last straw was when they decided to join Pottering's "lets forget Unix and make Linux into Windows" crusade. A terrible design decision on top of years of other questionable choices and bad attitude about actually listening to user needs.
I supported GTK and Gnome waaaaay back when they first started, when the fight was between a Free (GPL) library and the increasingly popular proprietary-license-only[3] Qt. Now, I'm not sure what to support in the GUI toolkit area.
While I figure that out, my current project's GUI is being written in ruby-tk. The widgets in Tk have a terrible look and strange layout/interaction quirks, but at least it isn't a moving target and work more or less everywhere.
[1] e.g.: writing Ruby bindings C++ libraries can be problematic. While problems such as the name-mangled symbols are not as bad as they once were, it is still much easier to link a C library into a random environment.
[2] As Linus said, "...thou shalt not break working code."
[3] Trolltech changed the license about a year (?) afterwords.
It's unfortunate that Linux and/or Linux distributions have not yet solved the problem of supporting parallel versions of dependencies. Even Node's package manager supports that. The end result is that rolling release distros break stuff often, as applications can't be tested and executed in isolation of each other. The "solution" to this is releasing everything every 6 months, when you can actually test everything together, then stop providing new versions for months.
If Linux/Linux distributions did support it, rolling release would be a lot more common. One limitation that would remain is that if you have an application that requires a single instance (e.g. a Network Manager), you couldn't have multiple instances of it running at the same time.
The goal of an operating system is to run applications. The installation and packaging of software should be as simple as possible.
For whatever reason, the Linux desktop community does not see this as an issue.
If I want Vim 7.4, 7.3 and 7.1 installed at the sametime, your package manager should support it. What if 'X' plugin is only compatible with 7.1 and 'Y' plugin is only compatible with 7.4. This is a valid use case.
Lately, I have been using Docker to work around this, but it's not fun setting up GUI applications in a container.
> Even Node's package manager supports [parallel versions of dependencies]
I feel like your emphasis is backwards.
It's not surprising that NodeJS, a new project, has solved some of these problems. NPM has the luxury of decades of experience from dozens of linux package managers and package managers from other languages. Plus, they're not tied to the legacy use cases the same way that (e.g.) apt is.
Well (I think) part of the whole point of a package manager is to reduce space by sharing dependencies. Npm seems to actually store a copy of the dependency individually for each package that requires it. I really think that is inefficient and a step backwards.
> It's unfortunate that Linux and/or Linux distributions have not yet solved the problem of supporting parallel versions of dependencies.
They do and they have, but they can't conjure-up libraries that haven't been properly versioned and released upstream.
If the GTK+ team can't maintain an ABI then they need to start releasing versions under different sonames such that programs like wireshark link against "libgtk-3.so.0.1200.2" and not "libgtk-3.so.0", then the package managers will be able to do the right thing.
"It's unfortunate that Linux and/or Linux distributions have not yet solved the problem of supporting parallel versions of dependencies."
Uh, they have. For ever.
I have parts of boost 1.49, 1.53, 1.54 and 1.55 together on my system. I have GTK2 and GTK3 together on my system. I have Qt3, Qt4 and Qt5 together on my system. Python2 and Python3. libpoppler19, libpoppler44 and libpoppler46.
I really think this is exaggerated a lot. Maybe we don't use a lot of complex features, but at sugarlabs we have written a whole desktop environment and app ecosystem based of gtk3. We use the python gtk3 wrapper and I think there was only 1 instance this year where gtk3 broke our ui (icon_size got removed or something like that). We also use a lot of other gnome things (eg: gsettings) and those don't seem to be an issue.
Parts of the gui that used to render correctly now stops updating at all.
I suffer this problem with an image viewer (geeqie) on debian. I have to restore/maximize the window to force a redraw and it has been like that for months.
It would be nice, if the author would back his claims by specific references. Comparing the upstream tracker reports for GTK+ and Qt shed a different light on ABI compatibility between versions:
We loved GTK. It let us do great things for so many years... it was a necesary step while there were no other LGPL libraries.
But we got rid of it, changed all our code to Qt, which run circles around GTK Never looked back, best decision we could ever make. It works beautifully in all platforms, it integrates OpenGL, pdf output, printers support.
The only problem about Qt is that not all open source programs use it, so you use Inkscape(GTK) in Mac and works so badly, you can't even copy vectors(it copies pixel images instead!!).
I actually like writing GTK way more then Qt. I like the fact it is C and easily integrates with any language I wish to use.
Though I use Qt, the Mac support on GTK is terrible at best. Windows support is even worse (or non-existent) which makes me question their "cross platform gui" title.
If I was to suggest a method, I would suggest using each platforms GUI language and make a backend in something cross platform.
There is a lot of truth in this but it does take a very lazy attitude to testing.
The simple truth is that if you need your application to support certain distributions, you need to be there on the development releases testing them and either submitting bug reports or improving your application.
And you can automate much of this with a pile of bootable ISOs and a scriptable virtual machine. Testing isn't new.
I release an application "today" (and "today" for example is when Gtk 3.4 is released), and six months down the line the Gtk team decides to release Gtk 3.6 which breaks just about every application that has a GtkTable. As an application developer, I believe I have a right to be pissed.
How do I file a grievance? I go to the GNOME bug tracker to find my bug. CLOSED: WONTFIX - we don't care, our solution is you port to GtkGrid. Doesn't matter to us that you now have to bifurcate your codebase to work with people still running Gtk 3.0 or 3.2, or choose to ship your own built version of Gtk 3.4 with your application. Fuck you, application developer.
What do I do to mitigate the impact? Well, I have to spin an emergency release of my application, despite the fact that no other code might have changed, just because the Gtk team decided that breaking ABI was no longer a concern for them.
Now multiply this for basically every Gtk cycle from 3.4 to 3.1(3/4) and you realize the problem.
It's not fair to put all the blame on the end developer IMHO.
I mean, in Windows, Microsoft obviously take care not to break binary compatibility - even across several generations of OSes. Right now, in my Windows VM I can run Office 97 on Windows 7 [1].
That's an 18 year old piece of software. And it's still working fine.
I upgrade Ubuntu and it's a flip of a coin whether Google Earth will stop working.
Can you explain testing actually solves this problem? The problem is multifaceted: it involves the behavior changes of a Gnome, which testing will find, and the unwillingness of some distros (I would imagine Debian is in there) to release new software for reasons other than security fixes, which testing doesn't and cannot address.
The author makes it clear updating his code to fix the problems is not the problem.
FYI, for those who want to write cross-platform GUI apps but prefer to avoid C++ (even the mildly nicer Qt flavor...), there are alpha-quality go bindings for QML.
Folk who want to develop cross platform software GUI software should use Lazarus. It works on Linux, Windows and OS/X. Getting started can be dicey, what once you are up and running it simply works. The LCL doesn't use the latest Qt5 or Gtk3, but it just works.
Linux guys should stuff faffing about with endless compile times in C++, buffer overruns and pointer exceptions. They should use FreePascal and Lazarus and retain their sanity.
I'm actually teaching myself Xt Intrinsics and Xaw, because "lateral thinking with withered technology". It's crazy, I know it's crazy, but when I read about what a moving target the new hotness is, I wonder if there isn't some kernel of wisdom in looking to the battle-tested technology of the past for inspiration.
>How does one shield oneself from this, i.e., how does one ensure that the binary compiled (say) three years (or months) ago continues to work reasonably?
Static linking should save you from from this hell. I don't know if gtk even supports it, I know glibc does not, whitch is a shame.
ABI compatibility should not be a huge problem for distributions. They can just recompile all the packages linking against GTK+ when they update it.
The crazy stuff is having your window decorations disappear when running a GTK application under openbox because somebody thought it would be funny to screw with gtk+-3.12 [1].
Exactly. I feel like this post was blaming Gtk+ when it seems like the real problem was the distro not realizing that their package dependencies didn't trigger a rebuild.
If something breaks ABI compatibility, that doesn't mean it is API incompatible. It just means all you need to do is recompile dependents and everyone's happy. It sounds like almost all of the problems in this post were caused by a failure to rebuild dependents. That's a general problem that can affect any library, not just Gtk+.
This is why I prefer Crunchbang Linux (or more generally, a good OpenBox based distro) to Xfce or Gnome 3 these days. I can freely switch between using a GTK app and its QT or other toolkit-based equivalent, assuming such equivalent exists, without the risk of breaking anything on the GUI side. With QT in particular becoming much more modular, I also don't end up with hundreds of megabytes of KDE bloat to support one 10MB app.
[+] [-] jbk|11 years ago|reply
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
[+] [-] icefox|11 years ago|reply
[+] [-] currysausage|11 years ago|reply
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?
[+] [-] aceperry|11 years ago|reply
[+] [-] cm3|11 years ago|reply
[+] [-] scrollaway|11 years ago|reply
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.
[+] [-] jeorgun|11 years ago|reply
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.
[+] [-] maxlybbert|11 years ago|reply
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.
[+] [-] jesuslop|11 years ago|reply
[+] [-] pdkl95|11 years ago|reply
I was even enjoying Vala. While it was obviously a young language, it had a lot of interesting ideas.
Then we got the new 3.x version of GTK with its "lets rewrite everything for no other reason than to break compatibility"[2] project goal that seems to have corrupted far too many projects recently. In addition to the problems already mentioned in this thread, it seemed so.. unfinished. Various components or features were gone or rewritten into something else. I guess they spent all their development time trying to tie Gnome and in as tightly as possible instead of finishing features.
The last straw was when they decided to join Pottering's "lets forget Unix and make Linux into Windows" crusade. A terrible design decision on top of years of other questionable choices and bad attitude about actually listening to user needs.
I supported GTK and Gnome waaaaay back when they first started, when the fight was between a Free (GPL) library and the increasingly popular proprietary-license-only[3] Qt. Now, I'm not sure what to support in the GUI toolkit area.
While I figure that out, my current project's GUI is being written in ruby-tk. The widgets in Tk have a terrible look and strange layout/interaction quirks, but at least it isn't a moving target and work more or less everywhere.
[1] e.g.: writing Ruby bindings C++ libraries can be problematic. While problems such as the name-mangled symbols are not as bad as they once were, it is still much easier to link a C library into a random environment.
[2] As Linus said, "...thou shalt not break working code."
[3] Trolltech changed the license about a year (?) afterwords.
[+] [-] currysausage|11 years ago|reply
Could you give a little more background about this? (True curiosity, I don't doubt that what you say is true!)
[+] [-] dviola|11 years ago|reply
[+] [-] skriticos2|11 years ago|reply
TLDR:
* Qt has a community of people developing applications, has good documentation (precise, good coverage) and people who care
* Gtk+ has a bunch of Gnome developers, if you want to develop an application, you're out of luck
[1]: https://www.youtube.com/watch?v=ON0A1dsQOV0
[+] [-] MBCook|11 years ago|reply
[+] [-] nawitus|11 years ago|reply
If Linux/Linux distributions did support it, rolling release would be a lot more common. One limitation that would remain is that if you have an application that requires a single instance (e.g. a Network Manager), you couldn't have multiple instances of it running at the same time.
[+] [-] sonofsam|11 years ago|reply
The goal of an operating system is to run applications. The installation and packaging of software should be as simple as possible.
For whatever reason, the Linux desktop community does not see this as an issue.
If I want Vim 7.4, 7.3 and 7.1 installed at the sametime, your package manager should support it. What if 'X' plugin is only compatible with 7.1 and 'Y' plugin is only compatible with 7.4. This is a valid use case.
Lately, I have been using Docker to work around this, but it's not fun setting up GUI applications in a container.
[+] [-] ikawe|11 years ago|reply
I feel like your emphasis is backwards.
It's not surprising that NodeJS, a new project, has solved some of these problems. NPM has the luxury of decades of experience from dozens of linux package managers and package managers from other languages. Plus, they're not tied to the legacy use cases the same way that (e.g.) apt is.
[+] [-] samdroid|11 years ago|reply
[+] [-] nly|11 years ago|reply
They do and they have, but they can't conjure-up libraries that haven't been properly versioned and released upstream.
If the GTK+ team can't maintain an ABI then they need to start releasing versions under different sonames such that programs like wireshark link against "libgtk-3.so.0.1200.2" and not "libgtk-3.so.0", then the package managers will be able to do the right thing.
[+] [-] jdjb|11 years ago|reply
[+] [-] Karellen|11 years ago|reply
Uh, they have. For ever.
I have parts of boost 1.49, 1.53, 1.54 and 1.55 together on my system. I have GTK2 and GTK3 together on my system. I have Qt3, Qt4 and Qt5 together on my system. Python2 and Python3. libpoppler19, libpoppler44 and libpoppler46.
[+] [-] samdroid|11 years ago|reply
[+] [-] bleh_|11 years ago|reply
[+] [-] matthiasv|11 years ago|reply
http://www.upstream-tracker.org/versions/gtk+.html http://www.upstream-tracker.org/versions/qt.html
(Yes, yes, Qt does more than just GUI, I know …)
[+] [-] Htsthbjig|11 years ago|reply
But we got rid of it, changed all our code to Qt, which run circles around GTK Never looked back, best decision we could ever make. It works beautifully in all platforms, it integrates OpenGL, pdf output, printers support.
The only problem about Qt is that not all open source programs use it, so you use Inkscape(GTK) in Mac and works so badly, you can't even copy vectors(it copies pixel images instead!!).
GTK should die.
[+] [-] raverbashing|11 years ago|reply
Qt, WxWidgets, or even something else.
I'm so glad the Web and Modern Browsers reinvented "desktop applications".
[+] [-] dubcanada|11 years ago|reply
Though I use Qt, the Mac support on GTK is terrible at best. Windows support is even worse (or non-existent) which makes me question their "cross platform gui" title.
If I was to suggest a method, I would suggest using each platforms GUI language and make a backend in something cross platform.
[+] [-] adamnemecek|11 years ago|reply
You might be the first person ever to say that.
[+] [-] oliwarner|11 years ago|reply
The simple truth is that if you need your application to support certain distributions, you need to be there on the development releases testing them and either submitting bug reports or improving your application.
And you can automate much of this with a pile of bootable ISOs and a scriptable virtual machine. Testing isn't new.
[+] [-] awalton|11 years ago|reply
I release an application "today" (and "today" for example is when Gtk 3.4 is released), and six months down the line the Gtk team decides to release Gtk 3.6 which breaks just about every application that has a GtkTable. As an application developer, I believe I have a right to be pissed.
How do I file a grievance? I go to the GNOME bug tracker to find my bug. CLOSED: WONTFIX - we don't care, our solution is you port to GtkGrid. Doesn't matter to us that you now have to bifurcate your codebase to work with people still running Gtk 3.0 or 3.2, or choose to ship your own built version of Gtk 3.4 with your application. Fuck you, application developer.
What do I do to mitigate the impact? Well, I have to spin an emergency release of my application, despite the fact that no other code might have changed, just because the Gtk team decided that breaking ABI was no longer a concern for them.
Now multiply this for basically every Gtk cycle from 3.4 to 3.1(3/4) and you realize the problem.
[+] [-] michaelt|11 years ago|reply
I mean, in Windows, Microsoft obviously take care not to break binary compatibility - even across several generations of OSes. Right now, in my Windows VM I can run Office 97 on Windows 7 [1].
That's an 18 year old piece of software. And it's still working fine.
I upgrade Ubuntu and it's a flip of a coin whether Google Earth will stop working.
[1] http://www.microsoft.com/en-us/windows/compatibility/CompatC...
[+] [-] SoftwareMaven|11 years ago|reply
The author makes it clear updating his code to fix the problems is not the problem.
[+] [-] achiang|11 years ago|reply
https://github.com/go-qml/qml
[+] [-] vfclists|11 years ago|reply
Linux guys should stuff faffing about with endless compile times in C++, buffer overruns and pointer exceptions. They should use FreePascal and Lazarus and retain their sanity.
[+] [-] bitwize|11 years ago|reply
[+] [-] aksx|11 years ago|reply
I tried Qt and liked the fact that it had good libraries built in (using the provided networking library v/s using libsoup with Gtk+)
In my opinion Gtk+ with C is a big pain but Vala feels natural and should've been pushed instead of JavaScript by the gnome guys.
[+] [-] 1ris|11 years ago|reply
Static linking should save you from from this hell. I don't know if gtk even supports it, I know glibc does not, whitch is a shame.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] stefantalpalaru|11 years ago|reply
The crazy stuff is having your window decorations disappear when running a GTK application under openbox because somebody thought it would be funny to screw with gtk+-3.12 [1].
[1]: http://redmine.audacious-media-player.org/boards/1/topics/11...
[+] [-] davvid|11 years ago|reply
If something breaks ABI compatibility, that doesn't mean it is API incompatible. It just means all you need to do is recompile dependents and everyone's happy. It sounds like almost all of the problems in this post were caused by a failure to rebuild dependents. That's a general problem that can affect any library, not just Gtk+.
[+] [-] awalton|11 years ago|reply
That's just fine, until you want to release a binary application that targets more than one distribution...
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] morganvachon|11 years ago|reply
[+] [-] pipelone|11 years ago|reply
[+] [-] xamlhacker|11 years ago|reply
[+] [-] jmgrosen|11 years ago|reply