Fluffy @ LinuxTag

For everyone who is going to be at LinuxTag in Berlin tomorrow. Frederik is giving a talk on Fluffy, you really want to check this out. Also make sure to stop by at the the booths starting with K 🙂

Further reading on LinuxTag matters are available on the Fluffy website.

Paul Adams is also fluffying up for Alpha1!

In related news:

  • We are now also Fluffy on freenode: come visit us in #fluffy
  • Arrival of alpha 1 is very close (if you want to test the alpha1 candidate, poke me on IRC)
  • Work on a website has started, checkout http://fluffy.jussi01.com/ (thanks to Jussi for hosting)
  • More than 100 people like us on Facebook

♥ Stay Fluffy ♥

KDE + Distro + Package splitting = 100% fail for user?

…not necessarily.

For quite some time I envisoned a solution to the problem of package splitting and runtime dependencies (or recommendations at large).

Let me outline one very visible problem. Every KDE app got a Help menu in its menu bar (that is if it got a menu of course), in this standard Help menu there is an entry for documentation. This entry will open KHelpCenter, hoping for it to find the appropriate documentation.
In case of Debian/Kubuntu documentation is sometimes detached from the main package to decrease the package size. This is especially important for Kubuntu since the installation media of choice is a CD and thus Kubuntu needs to be very careful what the space is used for.
Here comes the problem. The user tries to access the documentation via the Help menu, KHC pops up and starts crying because it can’t find the necessary file(s) => KHC not happy = user not happy.

Granted, this is a distro-created problem, so KDE could not care (the excuse of being source-only distributor is always a good one, I used it quite some times myself ;)), but KDE wants to care. Any distro issue reflects badly on KDE (and to some degree also on other distros shipping KDE).

Let me give another example, where the user is not exposed to distro politics (such as installation media constraints), but rather law. MP3 support is technically available, yet most larger distros do not ship it by default, due to possible patent issues and what not. In Amarok 1 there was an interface that allowed distros to specify a way to obtain MP3 support at runtime. Amarok would start crying to the user and offer installation of the necessary components for MP3 support, user would either allow it to install all the magic or not.

My envisioned solution to all issues of this kind (i.e. missing runtime stuff) builds upon what Amarok 1 implemented.
In the best case scenario we have 2 information sources:

  1. The application knows that something is missing. This is most obvious, without knowing that something is missing it would be jolly hard to give an error message to begin with ;). Ultimately the application even knows what exactly is missing. For example, KHC would know that the documentation for knode is missing, because it was trying to access it.
  2. The distribution developer knows where the missing something is to be found (if at all). If the distro developer stripped the knode documentation, I would suppose they also know where they stripped it to 🙂
One source knows that something is missing and the other knows where to find it. Sounds like we just need to hook them up, right?
Let’s assume there was a library that could do exactly that. KHC cries a river to the lib, the lib looks up where to find the stuff, KHC is crying about, and offers the user to install it.
So, how would this work?…
  • The distro dev provides a desktop file describin how one would do package installation on $distro
  • The distro dev also provides desktop files for stuff that would be required at runtime or that was stripped intentionally. For example, there would be a desktop file knode-doc.desktop stating that the knode documentation is in package “kdepim-doc”
  • The application detects that something is missing and uses the lib to complain to the user
  • The lib looks up if it can find the missing component in the data provided by the available desktop files (e.g. looks for a desktop file about knode’s documentation)
  • The lib finds information and polls user whether to install the additional stuff or not
  • If user wants to install, then lib invokes whatever command is outlined in the desktop file, described above
  • If all goes well the lib notifies the application that the missing component is now available, thus the application tries to access it again
  • Hooray, all good (e.g. knode documentation is displayed :))
The trick is that you design the process in such a generic way that you can apply it almost everytime, some important stuff is missing (assuming the application knows what is missing precisly). That way you can apply the same solution for missing documentation, missing codecs, missing applicaton to open filetype (say I want to open a .exe, wouldn’t it be nice if KDE recommended the installation of package “wine”?),  improvements (nepomuk might recommend to use sesame rather than redland)…
Does this make any sense to anyone?

It didn’t get any better

Back at home (finally). I had to spend 7 hours at the Airport in Salzburg (that city with Mozart and classical music entertainment stuff) because I was far too drunk to drive home. Of course I didn’t just drink coffee and hack on neon+kde… because one doesn’t get much sleep @ LinuxTag, I decided to catch up on that: after sleeping on the table and in a bathtub, I ended LinuxTag 2008 with a quite long nap at the Airport, in the parking garage, in my car 😀

Anyway. It was an awesome event, again!

In more interesting news ;-):

  • Neon KDE nightly packages for Kubuntu are building right now (i.e. heading fast towards publishing)
  • I hacked a bit on the openSUSE Build Service integration which is next on the todo
  • Apparently I became MOTU Mentor (I really have no clue how this happened)
  • Amarok 2 is pretty much like Nokia – connecting people
  • Karaoke is fun