• Can you imagine you just copy one single file onto your system, wherever you possess "rw" privileges (no need for being root) and this file represents a complex, runnable application?
• Can you imagine that with a simple click on a website you could "copy-install" and run such an application?
• Can you imagine that this simple "installation" did not affect in any way the stability of your base system?
• Can you imagine that this file could even run from a USB pen drive? And you just stick it to a different computer to run the application there?
• Can you imagine that you could run the latest official Krita release side by side with Boudewijn's code from last night, without the two versions interfering with each other?
• Can you imagine you revert to your old system again by just deleting one file?

• It would provide a way to KDE developers for making binary packages of bleeding-edge code directly available to be run by usability experts for early feedback...
• It would let KDE developers give out their bleeding-edge packages to beta-testers well before Release Day...
• It would let translators see (in their actual, lively GUI context) the strings they are working on...
• It would enable art designers to actually *run* a program they are contributing icons and other artwork for...
• It would give a full preview of what will go out to our users at Release Day, to all the different groups of our non-technical KDE contributors (who are not typically compiling KDE every night from the latest checked-out sources)...
• It could happen at any time, completely independent of releases, practically 5 minutes after the code was written and compiled, and long before there are official packages created by everyone's favorite distro...

One can dream, no?

At aKademy I discussed this question with various people. By now everyone in the KDE community is aware of one of my proposed solutions (or that's what I like to think): use a NX or FreeNX driven KDE Application Server, and provide remote access to the programs in question.

However you are wrong if you imagine that my only occupation is NX. I have another, complementing proposal about how to tackle this same problem. One that is an especially nice fit in cases where testers and users do not have network connections.

One that works for Live CD distributions (Knoppix, Kanotix) as well as for Debian, Linspire, Ubuntu, Kubuntu and openSUSE/SUSE Linux 10.0. (No, it's really got nothing to do with NX. Nor with FreeNX. Other than the fact that Fabian, the main developer of FreeNX, has also been a contributor to this klik thingie...)

Take note! It's not a dream. It is reality. It is reality for Linux. It is reality for KDE. It is called klik.

It works on most Debian systems, and on Knoppix (torrent) and Kanotix (torrent) Live CDs.openSUSE/SUSE-10.0 is has recently been added to the list too. Here's how you can test it:

• Install the klik client: press [Alt]+[F2] and paste:
  wget klik.atekon.de/client/install -O - | sh (this step is not required on Kanotix -- it has the klik client already installed).
• Follow the instructions that pop up on your screen.
• Start Konqueror (it may have opened automatically), and click on one of the links offered in the online klik store.

You could also just type klik://xvier into the Konqueror address field. I actually do recommend to you to start with xvier: it is a simple game that fits into a less than 400 kByte download, so you can have a quick success with klik and see what potential it has...

Neat, isn't it?

klik has been developed by Simon Peter (a.k.a. "probono" in IRC), with the support of Niall Walsh ("bfree"), Jörg Schirottke ("Kano") and FreeNX's Fabian Franz ("fabianx"). You can meet them in the IRC channel #klik on Freenode.

If you are bit security concerned, you may want to know what klik does to your system. Here's the pitch:

• Its .cmg files are self-contained AppDirs (applications directories), compressed into a cramfs or zisofs file system.
• To run the contained app, klik mounts the bundle file underneath /tmp/app/1/ and runs it from there; if mounted, the bundle looks like it is a subdirectory expanded into the real directory structure of the host.

It's very much similar to how applications on Mac OS X works....

If you are even more cautious, or paranoid, you surely want to investigate more closely and see how klik operates on your system. Follow these steps to find out more details:

• wget klik.atekon.de/client/install (this downloads the install file without executing it).
• less install (this lets you look at the installer code: fear not -- it's pure shell).
• less $HOME/.klik (this lets you look at the "commandline client+klik protocol handler" code, of course only after running the klik client install).
• less $HOME/.zAppRun (this lets you look at the commandline starter for klik-ified AppDir bundles, also executed if you just click on one of the .cmg files).
• less {$KDEHOME,$HOME/.kde}/share/services/klik.protocol (the secret behind the klik://my_cool_app links, part 1).
• less {$KDEHOME,$HOME/.kde}/share/applnk/klik/klik.desktop (the secret behind the klik://my_cool_app links, part 2).
• less {$KDEHOME,$HOME/.kde}/share/applnk/klik/.directory (why there is now a klik icon and a klik entry in the K Menu).
• less {$KDEHOME,$HOME/.kde}/share/mimelnk/all/cmg.desktop (why klik is now responsible for handling clicks on files that happen to have a .cmg suffix, part 1).
• less {$KDEHOME,$HOME/.kde}/share/applnk/.hidden/AppRun.desktop (why klik is now responsible for handling clicks on files that happen to have a .cmg suffix, part 1).
• less /etc/fstab (why klik can now find mountpoints in the file system to mount the .cmg AppDirs on execution).
• ls -lR /tmp/app/{7,6,5,4,3,2,1} (list the directories underneath the mountpoints while one of the .cmg AppDirs is executed).

klik's smartness is all contained in a few shell scripts and typical KDE config files, as you can easily see...

For most of the 4000+ packages available from the klik warehouse, the "download" consists of a "recipe". The recipe tells the klik client where to fetch the binaries from (in most cases .deb packages from the official Debian repositories), how to unpack them, and how to re-package and compress them into the final .cmg image. So the klik client does most of the work and builds its own .cmg file in most cases.

If you want to look at one such recipe, here is the klik recipe for Scribus.

There are other packages which have been built on the server (and hand-tuned and tested) so that they work with non-Debian distros too ("serverside apt"). In this case the klik://some-app link will fetch the ready-made .cmg from the URL the klik server names in his recipe. The special "klik apps for SUSE 10.0" repository is filling up by the day. Warning: currently this will only work for openSUSE/SUSE Linux 10.0, not for other Distros!

You may be interested in trying the following links, if you have more bandwidth (note: they'll not work for you unless you install the klik client). They work on openSUSE/SUSE-Linux 10 RC1 very well, and also support Knoppix, Kanotix, Debian, Linspire and Kubuntu (other distros are untested):

• klik://apollon (downloads 2.2 MByte)
• klik://firefox (downloads 10.0 MByte)
• klik://skype (downloads 10.2 MByte)
• klik://frozen-bubble (downloads 14.0 MByte)
• klik://ooo2 (downloads 114 MByte) - Martijn can use this to read .odt files easily!

If you are a type of person who likes to startup apps from the commandline, use the klik commandline client like this:

• $HOME/.klik klik://ktorrent (installs the cool KTorrent BitTorrent client).

This will prepare the .cmg AppDir bundle and run it once ready. Once .cmg file is on your system, the commandline to run it (without a repeated download) is this:

• $HOME/.zAppRun /path/to/app123.cmg (runs the application named app123).

I have already browsed the web with Alpha version 1.6a1 of Firefox to see if the hype around it is justified. To do so, I tried the old-fashioned manual installation of the klik-ified Firefox:

• mkdir $HOME/klik-downloads
• cd $HOME/klik-downloads
• wget http://opensuse.linux.co.nz/klik/10.0/firefox_1.6a1.cmg
• $HOME/.zAppRun firefox_1.6a1.cmg

I am pretty sure, that at least some of our beloved KDE-PIM hackers will like this new way to take a quick look at their valued competition, without needing to install it:

• klik://thunderbird -- the Beta 1 of upcoming Thunderbird 1.5, the Mozilla mail client (klik bundle, direct link)
• klik://sunbird -- Development version of Mozilla calendar application (klik bundle, direct link )

Now, developers, what do you think of a tool that lets you easily create binary snapshots of your own development versions in the form of those nifty "Don't Install, Just Copy!"- .cmg files? -- Which of you will be the first five to step forward and receive the service of getting their SVN weekly builds packaged as .cmg AppDir bundles, for the next 3 months?

I know Boudewijn has been struggling in the past to provide Krita snapshots to a dozen beta testers and non-technical contributors, and to help them compile the code, or to support them installing binaries he had built.

I also know that I definitely would love to get quick access to kpdf, KWord, amaroK, Quanta and Kommander snapshots which I can run on my stable system with the reassuring feeling that the most that can go wrong is that the test app doesnt run at all, and all I had to do is just delete it again, to have my system reverted to its original state.

What about our friends from OpenUsability.org? Would they appreciate such a service too? Have they ever looked at the added value klik:// can offer to our common development workflow?

<  |  >