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?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s