//log//

So much for that. Again. A while ago and in quite a verbose way I announced my move to KDE 4.x, specifically in the Kubuntu 13.04 distribution which I adopted in early alpha, as most of the time. Finally. After fancying with this particular desktop environment for quite a while. Well guess I’ll better keep quiet about things like that by now, sitting in front of an XFCE machine again as I write this, not ending up with a desktop that is “lightweight” or “un-bloated” but, well, with a desktop that seems to just have a better balance between features and usability, at the moment. Not sure. Some more thoughts on that to follow, read on…

Objectives and grains of salt…

Straight away, first off: I am interested in KDE because of, not despite its technology. I do not consider things such as Akonadi or Nepomuk to be pointless bloat but rather see both of them approaches that, from an architectural point of view, definitely do make sense in a state-of-the-art desktop environment. Consequently, making KDE “lighter” by disabling or removing either of these functions (as project KlyDE is trying to do) is not an option to me – by then I’d lose any reason to use KDE at all and go for a plain window manager or something the like. But: Having all these things at hand, I’d also like to see my workflows a bit improved compared to the status quo, not made worse. Achieving this goal obviously is possible only by relying upon KDE integrated applications as far as possible. Apart from making best use of all the KDE infrastructure, there’s another reason to do so by the way: The KDE infrastructure runtime consumes a bit of resources on your machine, so it makes sense only when used. From that point of view, using large “non-KDE” applications such as Firefox and Thunderbird makes things drastically worse because, even though the KDE infrastructure is around and running, it is not actually used. So that’s how I am looking at things, by now… And these points of view should be consumed with a grain of salt, as always: At the moment, I am using XFCE/Xubuntu on my day-to-day working machine and Kubuntu 13.04 exclusively in a VirtualBox installment, for reasons outlined below, after having exclusively been with KDE on all my machines for roughly a year of daily work. Down this road, and also during writing this, I learnt a lot about KDE, but I still don’t consider myself an expert. I’ve been doing some communications on various KDE mailing lists, and the things outlined here represent the outcome of both these communications and my playing with KDE, Google and friends. Comments welcome, of course.

Design

Starting out, one of the re-occurring pains I have with KDE always has been UI style design. Starting with their 1.x releases I always considered KDE to offer the better technologies while GNOME to provide the more appealing user interfaces. This hasn’t changed to date, even though the KDE/Qt styles have greatly improved ever since the visual abhorrence KDE 2.x used to be. Yet, in KDE I still totally miss something as clean and straightforward as, in example, the GTK/GNOME Industrial theme. KDE Cleanlooks theme possibly is closest to this, yet I still have to find a style of window decoration to go with it color-wise, and even played with distributions other than Kubuntu to see whether they do any better. Not much luck unfortunately, and I somehow have given up on finding a working, lean KDE color and theme configuration with a clean, limited color palette and clean icon set suited for (what I consider) professional use. GTK people still do way better here…

… and even this way, this is just a minor issue as I stated. It’s just visual stuff, same as knowing there still is no fully functional integration of GTK apps (for the ones I will still be using even in a KDE environment, mainly being Gimp and Eclipse), and same as knowing some of the system settings, such as default background images, KDM / LightDM login screens and the like, still leave a lot to be improved compared to XFCE, GNOME, elementary and friends.

Skype

More annoying, yes also of less minor nature is the mess Skype regularly used to cause on my system while still using KDE/Kubuntu for day-to-day work. Mainly being an XMPP and “open standards” guy, I dearly dislike Skype but, in some situations, am bound to using it without much choice. It’s not a really good choice, but at least, recent Skype versions mostly work well on Linux, too. Mostly, that is: On XFCE or GNOME desktops, Skype does just that. Plugged my Logitech USB headset, got things configured once, worked. By then I was sure to, whenever I use or need Skype (which is two to three times a week at the moment), I just find a quiet place, plug the headset, get done whatever needs to be done. On Kubuntu, the very first time I tried so, I spent roughly half an hour messing with Skype Echo Service, the KDE/Phonon audio settings, the PulseAudio configuration and Skypes very own audio setup unless everything worked the way it should. Not nice, but not that much of a problem either. The next morning when booting into my machine without the USB headset plugged in, KDE complained about some audio hardware missing and suggested removing its configuration, too. I tried to cancel this, as I wasn’t really sure what the system was trying to tell me that very moment – after all, an USB audio device is something that is supposed to not be around all the time, ain’t it? That’s, at least, what I thought. To cut things short: The very next Skype meeting I had to postpone, because, after plugging the headset again, nothing worked, and again I made my way through figuring out how to set it right… It didn’t change much, and I didn’t really find a way to ease this. Ultimately, I better learnt how to get it configured and planned five to ten more minutes before each Skype meeting to get audio set right. Minor nuissance, too, for something that happens just two or three times a week, but by now, in XFCE/Xubuntu, it’s still nice to see this just works. Seems KDE and the Phonon audio subsystem does something substantially different here; unfortunately, this Skype mess-up is the only effect of this “doing things differently” I noticed so far.

Mail

Talking mail, there’s one issue to be considered minor I guess, yet it is astoundingly annoying in day-to-day work. I still use desktop e-mail clients rather than just webmailers, and in my configuration there are usually five IMAP accounts, two belonging to my own domain, two for our corporate e-mail system, and one at Google Mail where most of my mailing list handling happens. All except one use a load of server-sided folders – in case of Google Mail those are for different “labels” in which mails automatically get sorted, in case of our corporate server these are shared Cyrus IMAP folders in which scripts and other users tend to sort new messages during the day, and in case of my “personal” domain these are just folders where I manually move things to then and now. All of these accounts do have inboxes, and in case of all of these accounts, “important” mails are the messages that end up in the inbox without automatically being filed to any other folder. Adding to that, I usually want to have the mailer minimized, using the system tray icon to tell me whenever there is any new mail of importance. And, I want to have a dedicated bunch of folders out of the many that actually are available when offline while I don’t need it for most of the folders.

In many possible ways, KMail is astounding feature-wise. In example, it’s the only(!) actively developed mail application I know of that supports working with server-sided sieve scripts used by cyrus mail server to do mail filtering. It also is the only mail client I know that supports cyrus IMAP access control lists and options such as setting a “shared ‘unread’ flag” per IMAP folder. All in itself it is a pretty powerful. And yet, for my use case, there’s one thing that makes it pretty difficult to use in day-to-day life: I haven’t found a sane way to use “new mail” notifications in the tray icon. With all the hundreds of IMAP folders in various accounts, the tray icon usually displays the amount of unread messages in all of these folders. With a bunch of internal users sorting into our internal IMAP server and several high traffic mailing lists being “labeled” in Google Mail, this usually amounts to several hundreds of new messages continuously. Some kind person on the mailing list pointed me way to how to disable this manually per folder, but ultimately, this is not something I’d manually like to do for several hundreds of folders. The thing that would be most logical (introduce an option to only show “new mail” notifications for folders in “favorites” / “preferred folders”) is not possible, neither obviously is inheriting the appropriate setting per folder to child folders (as can be done, in example, for local storage / retention policies – keep all messages locally stored permanently). Only real workaround I found here is setting “root” folders of accounts to never poll automatically (just download messages whenever the folder is being selected / opened) and overriding this individually per inbox. A bit clumsy but works and has the advantage of also reducing systemload a bit (see below, too). Dealing “favorite folders” a bit more intuitively would definitely ease things here…

Image management

Not that minor anymore, as I am pretty much into digital photography and imaging, is some of the confusion regarding image management I had to experience in KDE. Given I have been an avid Gimp user ever since its 0.9.x versions, I am still going with it, despite some issues in UI and image handling, and eventually I will so at least as long as there ain’t a viable replacement in KDE (krita – http://krita.org/ ain’t yet there in my opinion, and I am not sure it intends to be a Gimp replacement after all). I am, however, way less decided yet about which tool to use for managing large collections of images. Basically, I need a tool that allows for sorting images according to dates and custom keywords. First thing’s trivial in days of cameras correctly writing EXIF timestams. Second thing’s a bit more complex, taking into consideration that I want a tool that (a) allows for quickly adding many tags to many different (selected) images and (b) easily supports for keeping keywords all along with images in order to keep keywords also whenever images get stored to a DVD or moved to an external USB drive, worst of all eventually without an actual application or desktop environment running (i.e. from a terminal session).

For image management, KDE offers two applications – gwenview (gwenview.sourceforge.net/) and digiKam (digikam.org), first one being a light-weight, fully KDE aware image viewer / browser, second one, in one statement, being the most powerful and sophisticated open source imaging application I have seen to date. Both of them do have advantages and drawbacks, as usual. It is, same as usual, a bit more difficult however: While I really like digiKam feature-wise, talking about adding keywords to images I by far prefer the workflow implemented in gwenview which seems much more straightforward to me. Also, gwenview is completely integrated with KDE, so it does, as one would expect, keep its file metadata, such as keywords, in KDEs very own semantic desktop environment, the Nepomuk infrastructure, so they are available to each and every other KDE application, like the file manager (which is helpful).

Issue #1 here: gwenview only stores its stuff to Nepomuk, so the keywords, comments, … added here are useless as soon as you (or the images) leave KDE. So far, neither gwenview itself nor the Nepomuk infrastructure do offer any facility to keep metadata along with the images, and be that by writing keywords and the like to EXIF / IPTC headers. Thus, keywords kept in Nepomuk are unusable to any non-KDE applications, not even talking about transferring them in between different hosts.

Issue #2, which is worse: Though being a KDE application in itself, digiKam seems to have lost support for Nepomuk somewhere all along the way, ending up in the fact that digiKam keeps its metadata in its own proprietary isolated database, leaving any metainfo you add in digiKam unavailable to any other KDE applications. Same way, it’s not easily possible to use “best” tools for different things and utilize gwenview for adding keywords and digiKam for anything else as digiKam also doesn’t see Nepomuk stored metainfo added in gwenview.

This is not really nice, actually. At least digiKam is capable of storing metadata to EXIF headers, so workaround in KDE by now is using digiKam and hoping for Nepomuk to then and now rescan files and sync keywords, ratings, comments, … with its database so these information are available to gwenview, dolphin and the semantic desktop search, too. Been playing with pyKDE / pyexiv2 bindings and python for a while in order to write a script to sync KDE / Nepomuk based metadata back to KDE but eventually gave up on that a bit lacking time and motivation, see below. The fact that, despite it doesn’t actually use it, trying to install digiKam on a non-KDE system Ubuntu system will install the full Nepomuk infrastructure as well is pretty strange from that point of view, by the way.

Browsers

This is by far the most difficult thing once you want to stay “pure KDE”. Ages ago, with 2.x, KDE introduced Konqueror as browser / file manager / client to various kioslave / something that resembles the same integration Internet Explorer used to see in Microsoft Windows these days. All along with Konqueror came KHTML, at some point picked by Apple, turned into WebKit, and this way becoming the core of quite some of the most relevant web browsers to date. Konqueror is still around, KHTML itself is still around, Konqueror learnt to also use WebKit in the meantime, and all along, too, came a new browser dubbed rekonq (rekonq.kde.org), supposed to be a “lightweight” new browser based upon WebKit too and being default in recent versions of KDE. I am these days playing with both of them, and again, both seem to have different advantages and drawbacks. rekonq, in example, does better when it comes to providing access to (WebKit) developer tools whereas konqueror generally offers a wider range of features and configuration options. Using the WebKit subsystem in konqueror (instead of the KHTML one it defaults to), both browsers do well opening the same web pages, and they do so well for most pages that work with WebKit, not too much of a surprise.

And yet, in my environment, they both fail in some way:

• Being a web backend developer, I am at the moment still relying upon a web browser for interacting with RESTful services. While Firefox and Chromium offer extensions or add-ins to make interaction with RESTful resources a breeze, none of these tools are available to any of the both KDE browsers. Worse, neither one of them is even able to correctly render or display Atom XML feeds, and displaying formatted JSON also fails, even after some fiddling with katepart, konqueror and some arcane kate plugins. Not even talking about adding custom HTTP headers or using methods other than GET or POST.
• We internally use a chiliproject (www.chiliproject.org) installment for ticket tracking, which is configured to use HTTPS/SSL with a self-signed certificate for automated user login and sends around e-mails with links to tickets or wiki pages including, of course, HTTPS links. These work in neither rekonq nor konqueror. At first, obviously KDE lacks sufficient certificate management features to allow for importing the SSL certificates required to work with this setup.
• Worse, again, is that clicking on the links themselves doesn’t do anything. In rekonq, after clicking such a link, I am confronted with an empty error page and an empty URL bar which stops me from doing the most simple workaround (manually changing the protocol scheme to “http” and manually logging in to the tracker) because the URL in such a case is not visible. I even filed an issue for that a while ago (see bugs.kde.org/show_bug.cgi?id=312928) which however hasn’t really seen much attention ever since. Configuring konqueror to be the default browser, I don’t even get to see a browser window but, whenever clicking one of these links, am about already see kmail complain about a connection error (“SSL handshake”).

The REST thing easily can be worked around by using a standalone REST client outside the browser (such as the one found at code.google.com/p/rest-client/), which is just a matter of getting used to. The HTTPS issue basically can just be worked around by always manually logging in to the ticket system and copy-paste’ing over links and manually setting them to use the right scheme in either konqueror or rekonq. Both ways somehow work, but both ways seem workarounds that don’t really provide additional value, from a usability point of view, but rather make things worse and more complicated than necessary.

Load issues, infrastructure, use cases.

Initially I stated that I don’t consider KDE bloated as far as features such as Nepomuk or Akonadi are concerned, but I would like to make some more nuanced statements on that. Overally, yes, I would like to have a semantic desktop, and many of the potential benefits provided by Nepomuk definitely seem worthwhile. Same way I like Akonadi as an integrated PIM system which, in some ways (talking a “server infrastructure” and “client applications” working on top of it) seems in some ways way more Unix’ish than many other desktop applications these days.

Yet, I wonder how much different infrastructural technologies really are required to drive this, or whether it wouldn’t be possible to make the system as a whole leaner without having to give up on any of the good features it provides. Looking at the specs of most computers available to date, I don’t think running, say, an RDBMS all along with a desktop environment shouldn’t be too much of a problem. But, more than once I experienced my system responding slowly in situations of using the semantic desktop while Akonadi was refreshing some of its resources, and, by then, seeing both openvirtuoso and mysql heavily consume CPU cycles and RAM, I wonder whether we actually need the both of them. Why not, as a standard installment, rely just upon an RDBMS and make the openvirtuoso an optional component? Sure, a triple store is something else than an RDBMS, but eventually storing triples in mySQL or mariadb or wherever should probably be easier than storing all the Akonadi content in an RDF structure. Maybe it would slow down things a bit, and maybe some more “power” users still would use the triple store after al, but I certainly wonder whether this wouldn’t be a good option to make some of the (actual? perceived?) “bloat” in KDE disappear, make things a bit lighter in a place where it should be possible. Maybe all along providing easy interfaces to storing things in / loading information from the RDBMS, this also might be a good way to show end users why this is a good thing to have and why they should care.

Talking “why should they care”: Exactly the same in my opinion goes for the whole Nepomuk / semantic desktop infrastructure. Neat to know KDE, on top of Nepomuk, can provide a list of recently edited files and the like. But shouldn’t be more? What about a quick find in dolphin to reveal information like “who (e-mail, xmpp, …) has received the selected file via ‘send as …'”? What about queries such as “which PDF documents (with extracted XMP metadata) have been authored by the guy (identified by an e-mail address) I am currently looking at in my Kontact application”? What about a “project organizer” application that pulls together images, files, contacts, e-mails, web links, … based upon annotations such as “belongs to project X in milestone Y”, stored in Nepomuk? The whole idea of semantic desktops could provide answers to a whole load of interesting use cases, but as far as I would say, all implemented in KDE at the moment basically boils down to doing things already done before, just this time doing them backed by Nepomuk.

Odds and ends.

So, finally and after all, my conclusion is: I really admire KDE for many of the things it is all about, yet again I am not using it at the moment and repeatedly fall back to XFCE / Xubuntu in day-to-day work. It’s not specifically to any of the issues outlined here, it’s merely a decision caused by a bunch of minor things, including these outlined here, including the fact that essential applications in my stack, such as Eclipse or Java/Swing tools (using GTKLaF) so far fail to really look and feel consistent and integrated within KDE – starting with theme, colors, fonts, ending with things such as “favorite folders” / folder bookmarks to be found in file dialogs. None of these issues in itself is a “show stopper”, but in total they sum up to a situation where working with KDE full-time, at least to me, is difficult way more than easy or pleasant. Roughly for six months I’ve been exclusively doing everything in my day-to-day computer use using KDE. Moved to Kubuntu 13.04 builds pretty soon, and tried to actually follow up with that initially stated paradigm – just using fully KDE integrated applications, for the reasons I outlined – changed my mind on that rather soon, after spending a while messing with rekonq, konqueror, kparts and all, by switching to Chromium as a browser next to rekonq, initially just for REST client stuff, but more and more for internal tracker things and, then, one day, as “default browser”. Next, moved from both gwenview and digiKam to shotwell (www.yorba.org/projects/shotwell/) – a bit slower than gwenview, way less powerful than digiKam and absolutely not integrated with KDE at all, but straightforward and usable in just the things I need.

When I thought about replacing KMail with Thunderbird again, I decided I’ll rather keep watching KDE, using it on a VM, see where it will be heading, instead of using it in day-to-day work. I still believe KDE to be the piece of desktop most likely to add completely new aspects and approaches to the (then and now boring) world of FOSS Linux/Unix desktops, completely asides just adding eye-candy such as translucent windows or 3D desktop effects. Some of its features and applications are outstanding, and so are some of the technical concepts behind, yet unfortunately, in some places it just lacks the last piece needed to actually make it great and usable. Kubuntu and KDE both have come a long way here, but somehow (especially reading a bunch of rather strong and controversial messages relating to Nepomuk, Akonadi/Kmail/KDE-PIM and friends), it feels like there’s a bunch of work still left to be done. Maybe revitalizing the 100 paper cuts project? Maybe making KDE SC packages more look like “products”, same as the GNOME folks do? Or maybe, simply, I just should accept I’m not “target group” here, better shut up and stay with whatever works for me. No idea, really. 🙂

Filed under: