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?
Syndicate Blogs
Windows
Could klik somehow be made to work on Windows? Because I think it would be a great way to introduce Windows users to KDE applications now that they are all going to run on Windows.
Installation problems and solutions
This sounds a bit like something I mentioned in another discussion here at kdedevelopers.org:
http://www.kdedevelopers.org/node/1337#comment-3514
Have you looked at Zero Install?
Klik
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
- Aren't there live CDs of apps?
- translation lag is a problem that needs to get fixed. It requires too much skills to contribute to translations which means that the number of contributors is limited or on delay.
Live CDs vs. klik?
"Aren't there live CDs of apps?"
----
Yes, there are.
And how often do you update them? How long does it take to boot into them? How long have you to wait for updates to become available on them? How difficult is it to create them?
With klik, you could have daily updates. Heck, even hourly ones, if your cooperate closely with a coding developer, and are looking after his bugs and are discussing interface design with him via email, or IRC or Jabber across the globe. Been there, done that -- and had no klik at the time....
Do you actually take part in the KDE development process somewhere?
If you do so, you'll know that time is limited. You do not want to loose 5 minutes to reboot into a Live CD...
Klik's bad manners
Klik did something I definitevely dislike: it put an icon on my desktop. Arrrgh!
It took me a long time to realize --too many windows were opened on every desktops-- but when I closed Firefox... here was the xvier.cmg that I couldn't find in $HOME. I couldn't miss it. So white on an almost black background...
No way! When I see a bug crawling on my desktop --something that comes but that I didn't invite to-- I crush it with my big and dangerous mouse cursor!
More seriously: Why on the desktop?
I like very clean desktops --apart from the windows-- and I will never use anything that clutters them without my permission. Isn't $HOME a suitable place?
Apart from that, Klik is a nice thing in order that the average Joe doesn't have to worry about configure & make. Any way, I don't think it will become part of my everyday life. I prefer to stick with configure & make because there will always be un-klik-able things like a window decoration, a kicker applet, whatever, any system component that must be integrated in KDE and can't stand alone whichever way you try.
At least it has to ask
Klik did something I definitevely dislike: it put an icon on my desktop. Arrrgh!
I agree that this is an absolute no-no.
An installer which does this without asking for my permission first, isn't going to be used a second time.
Talk about bad first impressions, something that will make for example autopackage's life extremely unpleasent in the future (its first impression problem is that it used to be a potential system kill, installing in /usr without notifying the package manager)
I am always amazed how developers can opt for a decision where they know before hand that it will have a bad impact in the long run, especially when there are known solutions that don't
It's not an installer, krake!
"An installer which does this without asking for my permission first, isn't going to be used a second time."
----
I would be in full agreement with you, krake, if klik actually *were* an "installer" in the sense we tend to know installers.
But it isn't.
If you delete "the icon", you delete the .cmg file (the self-contained cramfs or zisofs tree melted into a loop-mountable single file), and thusly, you have reverted your system to its previous state.
It doesnt "install" anything into /usr, or into /bin or into /sbin, or into /usr/local .
It can run the klik-"installed" foobar-app, you can still run your system-wide installed foobar-app in alternation or concurrently without problems.
.
"I am always amazed how developers can opt for a decision where they know before hand that it will have a bad impact in the long run"
----
I'm also amazed. I'm amazed about the ability of some developers/users/people to publically comment about things they didnt even try to think through, or to test by themselves.
"especially when there are known solutions that don't"
----
Ha!, I would be very much interested in at least one "known solution" that does what klik does, without having its "bad effect".
Oh, and did I say you are free to *not* use klik, if you don't understand or like it?
Misunderstanding
But it isn't [an installer]
Well, it installs software, doesn't it?
I.e. making it available on the computer.
Anyway that wasn't the thing I was complaining about, it was the automatic, without question, putting of an icon on the desktop.
Actually if removing the icon also deletes the application, i.e. makes it unavailable again a.k.a deinstalling it, it is even worse.
A user installing an application through klik and then removing the icon because he doesn't like icons on the desktop, would, if I understand you right, have the impression that the installation failed.
It doesnt "install" anything into /usr, or into /bin or into /sbin, or into /usr/local .
I was referring to autopackage there. The autopackage developer made an even worse decision, i.e. to install into the domain of the distributions package manager without telling it about it.
I'm amazed about the ability of some developers/users/people to publically comment about things they didnt even try to think through, or to test by themselves.
True, shouldn't do that, but I was pretty sure klik made that icon installation non-optional.
You seem to confirm that.
Ha!, I would be very much interested in at least one "known solution" that does what klik does, without having its "bad effect".
The known solution is to ask the user if they want a desktop icon installed.
The implementations of that solution vary from asking a yes/no style question, to having a checkbox pre-selected which a user can unselect if the icon is not wanted.
Even Windows application installers that will without any further thought change your filetype associations usually ask for that.
Oh, and did I say you are free to *not* use klik, if you don't understand or like it?
True and I'd like to add that I don't have anything against klik technically, only behaviourally.
Assuming that it is technically possible for klik to not install the icon or ask about it, this might be changed on the future.
My main point however is, that any bad impression earlier versions caused will stay in people's minds for longer than the actual problem.
Thus my advice to really consider using unwanted behaviour in the first place.
I really like the idea behind klik so I really hate it to have it spoiled by something IMHO easily avoidable
target: endusers or...?
"Actually if removing the icon also deletes the application, i.e. makes it unavailable again a.k.a deinstalling it, it is even worse."
----
If you are not yet familiar with "moving" objects (on the desktop, or in the file system) come and visit #klik. A few people will be around that help you to learn this. It's easy.
"I really like the idea behind klik so I really hate it to have it spoiled by something IMHO easily avoidable."
----
You're invited to help improve what klik is now, to something that makes you totally happy. Again, visit #klik.
What we will not make compromises about:
* the "1 file == 1 application" paradigm.
* the goal to make it *most easy* to run third-party software (not handled by the system installer), and the same level of easyness to get rid of the same software again.
You are invited to create a KDE integrated klik client framework: this could include helper utilities to handle the .cmg files, place icons and menu entries into the GUI, keep track of moved .cmgs, look for updates, and "installer" that asks the user many questions, a de-installer.... whatever. You are invited to create an end-user software packaging and managing system around it, if you want.
We however, currently want to make it as easy as possible to distribute development versions of KDE apps to non-technical people who are *taking* *part* in the development. Did you get that? These people are not typical end users (but they are also not developers).
target: endusers that love having choices made for them
If you are not yet familiar with "moving" objects (on the desktop, or in the file system) come and visit #klik
I must have mistaken your previous comment. It gave me the impression that removing the icon from the desktop, i.e. selecting it and pressing SHIFT+DEL, would also remove the respective klik package.
But now that you have clariyfied that it is just another way to access the program it has been cleared up.
What we will not make compromises about
I am pretty sure that I never said anything against the technical choices made by the klik developers.
I am also pretty sure that those choice are good ones.
So, actually because I believe that there is lots of good thinking behind the concepts, I find it extremely unbelievable that the project wants to burden it with bad impressions.
Bad impressions are difficult to get rid of and spread faster than good ones.
Did you get that?
I did.
There must be some language barrier because I can't find anything in any of my statements that should make you think differently.
I have merely been warning about bad impressions in the beginning making it harder in the future.
Maybe I shouldn't have used autopackage as an example for bad first time impressions hindering later adoption, but I thought that it would be a good idea to use a similar project.
Anyway, after thinking about it I came up with a nice solution that even avoids asking questions:
In the event that I am going to install a klik program I'll just modify the access rights of the desktop folder so the creation of the icon is blocked and reenable it afterwards.
This will avoid cluttering my desktop while at the same time enabling me to quickly test programs