Library churn
I recently came across an old article by Benjamin Meyer titled A Tribute to KDE. In it (no, dash it, it's in something else I read today which I cannot find now), he notes the dearth of advanced applications using KDE. And even two years later, that is still quite true. Of course, we now have Scribus, which comes close to being not only usable, but the Free Software standard in its category, but there still isn't a Qt-based vector app that's even close to Sodipodi, nor a Qt-based raster image app that's breathing in the Gimp's neck. And while KOffice is getting better, Gnumeric is more highly regarded by them that think they need a spreadsheet, and while KMail is a great e-mail client, people flock to Evolution, of all things horrible. So, why is this? (And where has planetkde gone?)
Why? Despite Qt's and KDE's obviously superior libraries. A gnome-using friend and collegue recently had occasion to look at Qt, and was astonished to see that Qt not only was a more complete, cleaner and leaner library than Gtk, it offers more than the Gnome libs (if there's a way to define those: this was his subjective impression). And don't forget: both Qt and KDE are younger than GTK. Qt was started around the time the first Gtk-based version of the Gimp went final.
GTK and Gnome are in their secondses, Qt is moving to version 4, as will KDE be, once 3.3 is out of the door. And that's no mere numerology: these version numbers signify real advances, like themability, anti-aliased fonts and all kinds of advanced features like complex table widgets. Dash it, even with Qt 1.x, programmers didn't have to code their own scrollbar-treeview synchronization anymore. But these real advances take real work.
And not only from the library developers, also from the applications developers. And many app developers have been seduced from their apps to library development. Like Reginald Stadlbauer, the original architect of KOffice, who later did Qt's rich text engine. Doing libs is way more fun than doing apps with all their fiddly little UI details that are impossible to do in a satisfyingly generic way.
So, KDE (and free Qt apps) don't advance as fast as Gtk/Gnome apps because the authors have a chance to go and improve the libraries, but also because the libraries move at a fair clip. It took ages for the Gimp, nota bene the prima facie reason for the existence of Gtk to move to Gtk 2. All of KDE moves with kdelibs and Qt. And the relentless keeping up with ever-changing libraries is called churn. It's used by Microsoft as a strategic weapon. Trolltech and KDE don't use churn in this way, but it sure is hard to develop an advanced application and still keep up with the libs.
I really dread the Qt 4 porting move, and I should be spending time on the Oasis file format for Krita, and there's still workarounds for things from KDE 1.x and Qt 1.x in Krita that should go out (the layer box, for instance, is a custom widget that we needed because there was no table widget) and it's only recently that I ripped the plugin code for pre-KParts/KTrader plugins out...
And it's not just the lib developers; it's the users, too. KDE users have gotten accustomed to high standards of consistency (despite things like the previous-message key for KMail and KNode -- that's the topic for another entry), that they won't accept a situation where they need to run Qt 1, 2, 3 and 4 apps at the same time. By contrast, Gnome users don't seem to care. If I ask apt-get to install Gnome on my SuSE 9.1 system, I get applications using all kinds of Gnome and Gtk libs. Apparently that's the way it is, in that corner of the world. But KDE users want apps that conform to their current desktop.
So, keeping up with the libses takes time from developing insanely great applications... I wish I had a solution (apart from just forging ahead. Krita is going to be great, read my libs... No more redesigns.
/hacking | permanent link | |