+++ klik development taken up some speed, progressing rather nicely now +++ stop
+++ currently working on version 2 of klik client/runtime environment +++ stop
+++ moved all development activities to Google-Code +++ stop
+++ klik2 will no longer use shell/bash for the client runtime code, but python +++ stop
+++ loopmount from klik1 (with all its limits and (f)ugliness) is gone -- fusemount is the new king +++ stop
+++ klik1 did binary-patch away absolute paths embedded in its images -- klik2 will use completely unmodified .rpm and .deb and .tgz packages as ingredients +++ stop
+++ klik1 expected to be run on a debian-etch-alike host linux system -- klik2 will run on any distro that complies to the lsb 3.(1?) specification +++ stop
+++ klik1 mixed commandline with gui components (xdialog, kdialog, zenity) in one single bash script -- klik2 will sport a clean commandline interface and expose an API to write "native" gui frontends (Gtk, Qt, KDE, Tcl/Tk, PyKDE, PyQt, ncurses,... $whatever) +++ stop
+++ klik1 was alpha, proof-of-concept, ugly, hack-ish... software, but worked (if the recipe maintainer found time to do his job) -- klik2 will become stable, polished, cleanly designed... and will work even better (and therefore attract more recipe maintainers, with more time too 
) ++++
++++ first screencast of current klik2 in action (proofing how cool, easy-to-use and 'grandma-safe' klik2 will be once it is ready) in a Google klik2 Video (58 seconds) ++++
Go watch it!
Watched the video now? Disappointed because of the Gtk interface? You should be...
That's because "He, who writes the code, decides."
We just 'don't have no-one' to write Qt/KDE/PyQt/PyKDE/$whatever GUI code yet. But we have people who can write the Gtk stuff.... Do *YOU* want to be the one who makes the difference? Then come visit us in the #klik IRC channel on Freenode.
Syndicate Blogs
.tgz packages
You talked about .deb, .rpm and .tgz packages.
You mean source packages (tar.gz) or slackware binaries packages?
--
Under construction
I mean Slackware binaries, yes...
...or in fact any bundle of binaries that contain a "working" set of files that make up an application. These could be:
all of which formats are in fact supported by the current "klik1" implementation (and we don't expect this to be changing once "klik2" is ready for prime time
.
COOL!
wow.. just cool.. I've tried klik 1 once and you're right.. it wasn't useable... now that it also supports binary packages and the other great stuff you mentioned it will be a real improvement (at least for me (love to try out new programs) ^^)
so.. keep on the great work
ps: too bad that it's a gtk interface... would have liked it to be qt... I'm a dev but I haven't got time atm otherwise I would have looked into it. sry