"Don't install -- just klik'n'run!" -- a proposal for the benefit of KDE app snapshot testing

Friday, 16 September 2005  |  pipitas

So my Dot article about klik is now online. It has had already 40 comments within 2 hours, mostly positive. It contains a concrete, workable proposal how to accelerate KDE development: accelerating it by bringing our non-technical/non-coding contributors more closely to the "bleeding edge" code. We can do this by handing out bleeding edge binaries of KDE application development snapshots to our non-techies...

  • ...so they can run them without a complicated installation procedure
  • ...so they do not de-stabilize their work environment with installing some unstable system components into /usr/lib/
  • ...so they can easily delete it again and revert the system to its previous state when they do not want it any more (or if there is a new update for the app)

It can be made as easy as "klik and run" -- no, it is as easy as that already. -- (Hey, readers of the Planet SUSE: and it also contains some exciting news regarding some cool add-ons that can be brought to any SUSE 10.0 desktop in the near future.)

Why?

We all know that these indispensible groups (translators, documentation writers, artwork designers, bug reporters, usability engineers, PR people,...) do not typically compile their own working environment from sources. The (slightly simplified) picture is this: The non-coders often lag 6 or more months behind with what their desktop looks like, compared to what the coding part of our community has in front of them for their daily KDE-ing. This means f.e. that they report bugs against "old" released versions, packaged by their favorite distro -- while the coders are the only ones who see the applications running and can find bugs prior to releases. And the reports from bugzilla relating to released versions requires the developers to switch away from their bleeding edge environments only too often. If this takes too much time, it makes them more hesitant to do so -- and the bugfix is delayed.

Distribution of bleeding edge .cmg files can relieve that problem. If we had a "know good" repository of pre-build development releases of some key applications (updated nightly, weekly, monthly...whatever), this would bring a big boost to development. If translators could be provided with the actual interface of the new app/dialog they are currently working on instead of a boring string table view, this would probably bring an influx of new translators, and additional translation teams (KDE is already the project with by far the most translations -- 70, many more than Microsoft! -- but it does not yet cover the world completely). If our artists could work with applications while they are still in development, they may get a different inspirations as compared to just look at screenshots provided by the coder. If the usability engineers could start giving their input and suggestions right from the beginning of the development cycle (instead of after the first release), ...well, you get the idea.

  • The distribution of a klik-able AppDir file (.cmg extension) is very easy: just copy it to your system.
  • The execution of a klik-able AppDir file is very easy: just run the helper script with the .cmg as parameter: ./.zAppDir my-test-app.cmg
  • The removal of a klik-able AppDir file is very easy: just delete it.
  • The creation if a klik-able AppDir file is very easy: probono is currently in IRC (#klik on Freenode.net) stepping manyoso through the process to create a datakiosk.cmg
  • The internal structure of a klik-able AppDir file is easily understood: it is made of a compressed cramfs or zisofs filesystem, that can be mounted in userspace and executed by a simple helper shell script (".zAppRun").
  • The pre-requisits for successfull execution of a klik-able AppDir are easy: it is assumed that *some* set and versions of base system libraries is present on the hosting system -- everything else (libs, dependencies) is contained in the compressed .cmg image.
  • The danger posed by different versions of an applications and its libraries for the stability of a given base system is non-existent: everything the .cmg brings to your system is self-contained in the .cmg, and goes with the deletion of the .cmg, reverting your PC to the previous state (granted, it may have written into your $HOME/.dot-files or similar, but that is minor, and you can easily take care of that).
  • The opportunity to utilize KDE's cool Get Hot New Stuff technology to offer binary development snapshots of certain applications is a no-brainer: it takes just one small group of persons to do it.
  • The suggestion to include a new "make cmg" Makefile target is a great one: it would certainly simplify the creation of klik-ified applications even more.
  • The danger posed by wild criss-cross offerings of klik-able .cmg files around the internet opening up a way for "malicious-by-design" klik-ified programs is certainly there: this needs to be addressed. (But I do not think it is so much greater than for any other software/package/format a user does install from untrusted sources.)

What do you think?