Hysterical Raisins

I often see software developers who use Qt looking for existing solutions and libraries. Developers using Qt want IMAP libraries, a way to create Tar files, and more.

Many such cool classes and features are part of the KDE libraries, but are rarely considered by developers using Qt. To them it seems that KDE is bloated, or maybe that depending on KDE just for creation of Tar files is unrealistic. To a large extent that is false, as libraries from KDE come in granular form already. The kdecore libraries take up just 2.5 MB of space. The kdeui libraries consume 3.7 MB of space. For comparison, QtGui is an 11 MB binary. Parts of the KDE libraries already depend only on Qt, such as Solid, the hardware abstraction.

So it is true that we’re not doing at all badly already, but there are still areas we can improve. Part of that extra work is in communication (*cough*), packaging and build system improvements which have already been happening across the whole contributorship. It’s really great that I can run a command like

  debtree libkimap4 | dot -Tpng > kimap.png 

and get an image showing just how few dependencies there are these days for KIMAP.

Historical Reasons

However, there are still some interdependencies in the KDE libraries that may make adoption more tricky. You can’t have the plugin system or the asynchronous Job APIs without pulling in the localization system and the configuration system. This is the case largely for historical reasons and to some extent it is also possible to lessen that impact, but the currant state is that people who want to use parts of the KDE libraries fork the parts they want, and leave the rest.

I recently came across a word the Germans use to recognize situations like this in just a single word: Rosinenpickerei, translated as raisin picking. At first I thought, wow – The Germans have taken the concept of ‘Choosing the required/desired parts of a whole, and leaving the rest behind’ and squeezed it into a single word. Then I realized it was just like cherry-picking in English, so nothing to get all stereotypical about.

Turning it up to 11

Recognizing room for improvement, the KDE community organized a developer sprint meeting to focus on the platform and libraries right across the board. We’ve been running on 10 all the way up to now, and have come to the question of where can we go from here? We need that extra push over the cliff, so y’know what we do? We turn it up to 11. We have a in person face to face meeting for an entire week to tackle issues such as how we can improve Qt to make KDE software better. How we can improve KDE libraries to make the lives of Qt developers easier, and how we can improve the KDE platform to increase consistency among KDE applications.

That’s right,

10 Responses to “Hysterical Raisins”

  1. Julian Andres Klode Says:

    “Qt-using” would be easier to read than “Qt using”

  2. ary Says:

    I think the biggest hurdle for Qt-application-developers considering to use KDE libraries, is that those are very poorly documented (at least in comparison to the well-documented Qt libraries), and the documentation that does exist is very difficult to navigate without prior knowledge of where to find what. (And also, it is mostly aimed at “real” KDE developers).

    @Julian: Yeah, I had to read that paragraph twice, too.

  3. steveire Says:

    Thanks for the feedback. I removed the references to ‘Qt using’.

  4. Eshat Says:

    The command above should be without “> kimap.dot”
    I didn’t know there was such a niceway to display dependencies. Thanks for that

  5. Michael Says:

    @ Eshat: thank you for that correction–yes, this is a great way to view dependencies. It intrigued me so much, that I actually stopped packing for my move to see how this would look.

  6. Martin Owens Says:

    In a lot of ways, the KDE/Qt libraries are hurt by bad branding and poor fundamental library cultivation. It’s not as bad as gnome with their gconf and gvfs evilness, but it’s still bad and I will explain:

    If you took a library like KIMAP renamed it to ‘libimap-awesome’, take the parts it depends on and anything that mentions Qt or the letter ‘K’ either take them out or also rename them, then get some C/Python/Vala libraries in place to cover few bases.

    There, you’ve made a fundamental library that doesn’t depend on anything big and best of all it doesn’t depend on anything that developers perceive as being ‘KDE related’. (it doesn’t matter if it depends on things that used to be called ‘kde core libs’) You guys have to start changing tactics on creation of some of these cool technologies, rename them so we non-kde and non-gnome developers can use them without unnecessary fear.

    • steveire Says:

      I don’t think I can agree with you there. KDE is a strong brand already, and with the changes going on in Qt, we can try to reposition the libraries as ‘boost for Qt’.

      I don’t think abandoning libraries just because they have a K in them and rewriting them in Vala and python would help adoption in the Qt world. Working on embedded systems it doesn’t necessarily make sense either.

      Can you say more about ‘fear’ around use of KDE technologies? I don’t really know if it exists, and it’s quite fuzzy. The closest thing I’ve seen to it is users who think that they can only run KDE applications in a plasma environment, but that’s just confused users, not the target audience for libraries anyway. If you know more about fear of KDE do please drop me a line.

  7. Holy Cheese Batman! « Steveire's Blog Says:

    […] was a bit cryptic in my last post, though posts from others may be more clear that I’m at the Platform 11 sprint. There is a […]

  8. shevy Says:

    But Rosinen are a lot smaller than cherries 🙂

Leave a comment