This Time Self-Hosted
dark mode light mode Search

KDE vs GTK: who’s more portable?

I know this is going to be a flamebait, but for this time I’ll try to be as objective as possible. You all know that I started having KDE working on Gentoo/FreeBSD before any other window manager, but that was just because I use it and I feel comfortable with it.
Now it’s time to get everything working on Gentoo/FreeBSD, but there are a couple of problems.

First of all, we do have too much GTK1.2 stuff in portage, and it’s really really hard to make 1.2 work as there are lot of changes needed, and upstream is now dead. Also, it’s not possible to just use.mask “gtk”, and force G/FBSD users to use just GTK 2 (not that this is immune to problems, see later), as “gtk” useflag can enable gtk2 support if it’s the only GTK support a program provide, while “gtk2” useflag must be used with “gtk” flag, too. Also if this could seem absurd (why limiting Gentoo/FreeBSD while ports provides both 1.2 and 2 support), it’s an interesting experiment, as there are just too many GTK1.2 packages that just don’t work as they should and are dead upstream. GTK2 packages like beep media player are replacing old GTK1’s like xmms.

About GTK2, it’s true that the situation is surely better (as upstream is alive and kicking), but there are tons of patches in Ports that was never merged (probably never submitted upstream) and I can’t really stand all of them because I just really don’t know GTK2 and I have no contact with upstream to ask them to merge the patches.
At this point, I’d really like some help from a gnome herd dev to join Gentoo/FreeBSD and start looking at the patches to merge 🙂

From another side, I really want to thank Alberto Zennaro for the help with amaroK testing, that now works fine. If anyone tried it and it was crashing, the problem was that libtunepimp linked to libthr for threading support, but amaroK used libpthread, and the result was a not-good-at-all crash.

Comments 5
  1. KDE vs. GTK: Cars vs. fruits. Even if it doesn’t have much to do with the text, you can’t compare desktop environments and libraries for graphical user interfaces

  2. Erm, ok I was a bit sleepy while writing this :/The problem is: gtk2 portability issues doesn’t limits themselves to the toolkit code, but are reflected in gnome stuff, too. Qt and KDE, instead, doesn’t share even the make process, and the (unexistent) issues on Qt won’t reflect directly on KDE anyway.Probably a better title could have been “KDE apps vs GTK2 apps”.

  3. no, that’s still not correct. KDE is a desktop environment using QT, GTK is a library, similiar to QT. it either should be KDE apps vs. GNOME apps or just QT apps vs. GTK apps 😛

  4. KDE is not just a desktop environment, it also provides abstraction facilities that doesn’t get part of Qt themselves.A simple strictly-Qt application is on its own for portability, a part the generic supports provided by Qt directly, while KDE apps have a complete autotools support and better abstraction.

  5. Nothing wrong with comparing KDE apps versus Gtk apps when it comes to portability. You could also compare Gnome vs. Gtk or KDE vs. Gnome or KDE vs ncurses. Portability is a feature (or not a feature) of any library.I have heard from some (biased) FreeBSD developers that KDE is more cooperative with FreeBSD, mainly due to KDE’s fairly open commit policy.Thats interesting about the libtunepimp crashing. Bah. I wish errors like that would cause compile time errors. I wonder how many crash reports we get are due to mismatched thread libraries.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.