Quote Originally Posted by paradocs
Congratulations probono!
It combines an incorruptible base operating system
(except for the dog chewing on the CD)
with flexibility to easily add programs.
Exactly that is my intention. A rock solid, unbreakable "core system" that can be userland-extended with appications as needed without the risk of ever breaking anything. Personally, I have been using "poor man's intstall" of Knoppix as my main and single operating system for nearly one year now. I never had any problems with broken packages, forced upgrades and the like.

Quote Originally Posted by paradocs
It may change the "ideal" content of the KNOPPIX CD to
focus more on libraries and the basic support programs,
but free up space since applications can be easily
added.
Right. I think absolutely the same. The "core system" should be "stable" in terms of what packages it contains. In my opinion, it should include all the "low-level stuff" that is used in common by many applications, plus the latest KDE. It should also contain the larger "frameworks" (such as the LaTeX environment). Everything that is used by just a few applications instead could be klik'd.

Quote Originally Posted by paradocs
Can complex programs really be added on the fly?
In principle, anything (but kernel stuff) can. It really does not depend on the complexity of an app, but on how well designed it is. The least problematic are KDE apps. Nearly all of these can be klik'd without changes because they do not contain hard-coded paths. Instead, KDE uses variables such as "KDEDIRS", which can be easily set by the klik wrapper. Unfortunately, many other apps do include hard-coded paths, for example they expect a certain library in /usr/lib. The trick klik does here is to patch the binary to use ./../lib instead. This is a rather crude hack, but it does work for many apps. Some "frameworks" such as LaTeX are so reliant on hard-coded paths that I didn't get them to be klik-able yet. But in theory, there are no limitations.

What I really dream of: Convincing the debian developers not to accept hard-coded paths into the distribution anymore but I guess that will be a tough one...

Quote Originally Posted by paradocs
To invoke a klik shell program one types:
~/app-name/wrapper app-name
I know that is not ideal. The main problem is that many packages contain more than just one command line executable, and often the main executable does not even have the same name as the package (e. g. everything with "-utils" in its name). Please let me know if you find a solution for this.

klik right now is usable mainly for graphical apps. The typical command line user most likely knows how to use shell scripts in order t achieve his goals, or won't probably use klik in the first place. If he wants a klik'd command line app to be really "integrated", he will change /etc/profile or ~/.bashrc to include the PATH, LD_LIBRARY_PATH, MANPATH, etc. -> but this is not considered "professional" by some.

Since klik is KDE-focused, why don't we just make a menu entry for each command line app and open a konsole window? That's probably what I will do.