Stephan Sokolow (He/Him)

201 points
User profile image.
Ontario, Canada

Stephan has an interest in software freedom, human-computer interaction, user interface/experience design, programming, and Linux... but he prefers to leave graphic design to the experts.

Authored Comments

More common code definitely makes sense but there are a lot of reasons it's hard to pull off.

My understanding is that, in their most formative years, KDE generally came out with solutions first, which GNOME then reinvented because they weren't willing to budge on their dislike for Qt's custom pre-processed dialect of C++ and the poor performance of C++ compiled by older versions of GCC. (And that's assuming you only count the stuff after the Linux version of Qt got a GPL-compatible license)

That grew into a general rule of writing the core of GNOME in C, not C++. Apparently D-Bus is basically DCOP (first introduced in KDE 2, if I remember correctly), redesigned and rewritten in C to finally get GNOME on board.

I've also heard that, at least sometimes, KDE refuses to use GNOME-originated libraries simply because they consider the code quality to be too poor or the features too much work to reinvent. (While it wasn't an example of such a deal-breaker, much fanfare was given when GTK+ got support for putting widgets in an OpenGL canvas. Qt had support for that <strong>with</strong> input transformation months earlier.)

Also, I've seen quite a few examples of various individual developers working in or around the GNOME project simply not being the kind of people you want to rely on.

I know that, when it came to GStreamer, KDE actually <em>did</em> use it but, when a version bump (0.6 to 0.8, I think) changed the API enough to render their thin wrapper useless, they wrote Phonon, which is thick enough to allow runtime swapping of GStreamer, Xine, QuickTime, DirectMedia, etc. (To ensure that they could freeze the API for the KDE platform libraries for the entire 4.x cycle) In response, at least one of the GStreamer authors threw a tantrum.

Basically, the Qt-based and GTK-based library ecosystems have built up so much inertia due to their history and communities that it will take a gargantuan effort to take any truly significant steps toward re-unifying the underlying infrastructure. (Especially since the event loops, signal/slot systems, and so on which Qt and GTK+ implement differently are fundamental to the structure of existing applications and libraries.)

I have GNOME3 and LXDE installed on the same machine. I've had people who swear by GNOME3 confirm that the performance and responsiveness is as it should be... I'm so used to LXDE that GNOME3 feels unbearably slow by comparison.

Maybe it's because I value things like going from clicking a launcher to having a file manager window fully loaded and usable without further load lag in 500ms or less.

As for "power users" vs. "tweakers", I'm really curious to see how you defend GNOME's continued removal of useful features like compact view and the tree sidebar in Nautilus to chase some pie-in-the-sky GNOME-on-tablet-PCs vision.