Ideas on klik evolution

[probono]

You do not understand what klik is.
klik is _not_ an installer. Its philosophy is = "1 app = 1 file".
cmg files do not need to be "installed", and that is their biggest advantage.
Just think of them like mp3 files, you don't "install" those either in oder to use them, do you?

As for the "macros", what do you think a klik recipe is? What you describe is already there.

Greetings,
probono

[dmiceman]

You do not understand what klik is.
klik is _not_ an installer. Its philosophy is = "1 app = 1 file".
cmg files do not need to be "installed", and that is their biggest advantage.
Just think of them like mp3 files, you don't "install" those either in oder to use them, do you?

No, we understand this. Currently there is server-size package manager which do all the job, but please forgive me, i can`t believe what this is possible to live without introducing client-size helper -- some sort of package manager in other terms. Someone need to take care of new .cmg files (make in known to system) and deleted .cmg files (remove all traces of it from system). By the way, corresponding code in .zAppRun does not work for me, don`t know why yet.

As for the "macros", what do you think a klik recipe is? What you describe is already there.

They are programs If there will be something more intelectual on client site than currently used sh, it can cause problems because it is neary impossible to know what job this script designed for without running it. On the other side, i do not argue for using something like xml recipes which should be parsed and executed by rich client-side package manager (yet)

P.S. Right now i was tried to get some klik recipe to look at it closer, but klik.atekon.de become an unknown host!

P.P.S. Many peoples, including me see similarity between klik and Java Web Start technologies. What do you think about it?

[urielka]

ok haven`t been here a while
i am working on a klik deamon(it`s in bash but i think porting it to C/C++ or Python/Perl) it doesn`t need root permisons to mount images nither use fstab.
it`s the same way that KDE mediamanager works and MacOSX mounter(for dmg`s and iso`s) it`s a deamon that work at root-level so there is no need to have fstab coz the mounter can mount images coz it`s running from root but using signals you can tell him from a user-level program to mount something.

i have some time now so i can do things but i need some time to complete the deamon.
some things that the deamon will include:
1.handling recpices
2.mounting/unmounting cmgs
3.update menus(didn`t think about inotify so maybe it will be in the pre-1.0 now the deamon is only in pre-alpha so there is alot of things to do before this)
4.kio-slave isn`t a way for cmgs-kioslave can handle images only commpressed file.
5.intergaion with KDE mediamanger will be good but optional

my last goal on klik is a klik-based distro(not optimized but based so most of the apps will be klik`s)

just need some time.

Uriel

[dmiceman]

ok haven`t been here a while
i am working on a klik deamon(it`s in bash but i think porting it to C/C++ or Python/Perl) it doesn`t need root permisons to mount images nither use fstab.

Good news!

Do you want to make it work without FUSE? Currently, i`m trying to create fuse cramfs image handler and have some progress on it (right now it is mount images allow to read files from it and allow to list directories.. some times..).

Also, do you seen any code to read cramfs filesystem except kernel module? I was unable to find something like that abt here is a chance i`m duplicating someone effort..

[urielka]

no it doesn`t use fuse just normal mounting i think it`s a better way that using fusecram coz using FUSE is very difficult to install and config and not included in any distro but using my deamon works on every distro coz it use normal tools

[dmiceman]

no it doesn`t use fuse just normal mounting i think it`s a better way that using fusecram coz using FUSE is very difficult to install and config and not included in any distro but using my deamon works on every distro coz it use normal tools

Sorry, i`m not agree with you. FUSE is the future. First of all, next minor version of linux kernel will contain FUSE out of the box -- 2.6.14. It is awaited in next few days which mean what it will be included in all major distributions in next half of year.

But even now, it is not difficult to install it at all. It is as simple as runnung

./configure
make
sudo make install
sudo modprobe fuse

Gentoo, which i`m using make this work for me automatically when i`m issue command "emerge fuse".

[probono]

In my opinion, FUSE will be the way to go once it is part of the default installation in Knoppix, Kanotix, SUSE, Mandriva, Ubuntu, Linspire, Fedora, and others.

Greetings,
probono

[malignosama]

Mounting problem should be the main issue in the proyect, but I've no experience working with FUSE and whatever. An addition I would include should be a kind of link on the cmg's header.
For example:
An uncompressed version of the app icon.
The complete app name (the file's name isn't very descriptive many times).
A list of mime types the app supports (interesting for automatic setup of KDE or GNOME)
A way to execute application files/documents in the cmg file, for example, opening a PDF file using the Acrobat Reader in cmg mode. A script than mounts reader and opens the pdf doc on it. Of course this should be for AppRun