PDA

View Full Version : Ideas on klik evolution



sheldonl
09-18-2005, 12:15 AM
Hi guys, I have some ideas, not sure if they are valuable to you or not, actually, you've probably thought of them already, but here goes just in case.

There should be a klik ioslave. What would it do? Well, on downloading a .cmg file it would ask you if you want to install locally or globally. If globally it would install it to a shared location on the computer and add it to the system menu for all users and add it's icon to the system icon directory, fonts, etc.. If local it would download hte cmg file to a local directory, say ~/.klik/appdir and then add a link to your menu or even ask you if you want a link added to your desktop and add it's icon to your ~/.kde directory, fonts to where they have to go, etc.

Now, the klik ioslave would also be inotify aware (is in the newer linux kernels) so that if the cmg file is moved or deleted from these special klik directories, then the ioslave it automatically cleans up the menus and icons, fonts, etc. placed there by the program or updates them appropriately. It could also automatically remove config files put on the local system by the application. Of course it would probably have to keep a profile of any files that get added locally, but that wouldn't be too hard as a list of these files could probably be put in the the cmg files AppInfo file. This way you have proper application installation and integration with the system, as well as automated management of that application.

This idea could probably be extended further, but I think that with some work, klik is very very promising. If we could get everyone to standardize on this for anything at the desktop application level, then we essentially have fixed the Linux application install problem. (We could still have apt & dpkg/urpmi/yum & rpm, etc. system for upgrading system components)

Let me know what you think.

probono
09-18-2005, 12:38 AM
Yes, a kioslave would be a good thing, especially if it could
- Run applications from within a cmg without the need to mount it
- Display the icon contained inside the cmg

Similarly, it would be nice to see AppDir support in KDE as outlined on http://bugs.kde.org/show_bug.cgi?id=81772

Unfortunately, I'm not a C++ or KDE programmer so I can't be of much help here.

Greetings,
probono

dmiceman
09-18-2005, 06:29 PM
Yes, a kioslave would be a good thing, especially if it could
- Run applications from within a cmg without the need to mount it


Unfortunately, it is not possible on linux. You can`t run anything which can`t be mmap()-ed.

probono
09-18-2005, 07:35 PM
Unfortunately, it is not possible on linux. You can`t run anything which can`t be mmap()-ed.

If I remember correctly, there is a kioslave-to-filesystem binding that would allow accessing files inside compressed archives. It might go beyond the scope of KDE, though.

Maybe FUSE will be the solution, if it allows for clean userland-mounting (without the need for fstab entries), as it is the case on Mac OS with http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/hdiutil.1.html

Greetings,
probono

dmiceman
09-18-2005, 08:02 PM
If I remember correctly, there is a kioslave-to-filesystem binding that would allow accessing files inside compressed archives. It might go beyond the scope of KDE, though.

It is uses FUSE too. And as far as i know, it is discontinued.


Maybe FUSE will be the solution, if it allows for clean userland-mounting (without the need for fstab entries), as it is the case on Mac OS with http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/hdiutil.1.html


Yes, i`m fully agree with you. FUSE is an answer! Hard part of it is what cramfs fuse daemon should be written. But as far as FUSE will go to mainstream kernel (2.6.14 is coming!) it is only way to go in my humble opinion..

BTW: do you have any ideas to change cramfs to something more reliable? cfamfs is too restrictive from my point of view.

sheldonl
09-18-2005, 08:22 PM
Hi guys,

Well after looking into KIO and the way that you guys are doing things with klik, it seems that an IO Slave might be of limited utility (although I admit I'm not really really experienced with all of the uses of KIO). All it would really do it download the klik recipie to the local system and run it to create your cmg file. Once you have the cmg file there are more uses for it, like installing local files, icons, menu entries, etc. What would probably be more useful is a service that listens to a directory like ~/.applications and /opt/share/applications or /usr/local/applications and installs/uninstalls those things automatically when as file is added to or removed from that directory. Then you wouldn't need an IO slave at all. However, this would require a descritpion file to be installed in the cmg file to tell the daemon what files to install and uninstall to the local system when the program is installed or uninstalled to one of those special directories.

However, it seems that some recipies are not without their problems. For some reason some programs don't work properly. e.g. ksirc doesn't save my preferences or anything. I think that the IO Slave is of much more utility if a recipe is *not* a shell script, but a series of MACRO actions that are interpreted into actual actions on the file system by the daemon. These MACRO's could be defined by plugins to the daemon (service) and be written in shell, perl, python, c, c++ etc. I could probably use the plugin and MACRO code from lineakd to do this but it's a pretty large undertaking, it involves completely standardizing, codifying and reingineering the klik system. However, then each distribution can write macros that are specific to them and you don't have to put platform specific code into the the recipie.

Sheldon.

dmiceman
09-18-2005, 08:42 PM
However, it seems that some recipies are not without their problems. For some reason some programs don't work properly. e.g. ksirc doesn't save my preferences or anything. I think that the IO Slave is of much more utility if a recipe is *not* a shell script, but a series of MACRO actions that are interpreted into actual actions on the file system by the daemon. These MACRO's could be defined by plugins to the daemon (service) and be written in shell, perl, python, c, c++ etc. I could probably use the plugin and MACRO code from lineakd to do this but it's a pretty large undertaking, it involves completely standardizing, codifying and reingineering the klik system. However, then each distribution can write macros that are specific to them and you don't have to put platform specific code into the the recipie.

That is bring up another question: how much infrastructure should be on target computer when it trying to handle klik: link. If recipe will be macro, then there should be some sort of package manager installed already on computer which can process incoming recipe into instructions like: get this file, register some mime type handler, etc, etc.. That is not bad, but it is more difficult task. And it is require much more specifications, definitions, etc..

sheldonl
09-18-2005, 10:29 PM
However, it seems that some recipies are not without their problems. For some reason some programs don't work properly. e.g. ksirc doesn't save my preferences or anything. I think that the IO Slave is of much more utility if a recipe is *not* a shell script, but a series of MACRO actions that are interpreted into actual actions on the file system by the daemon. These MACRO's could be defined by plugins to the daemon (service) and be written in shell, perl, python, c, c++ etc. I could probably use the plugin and MACRO code from lineakd to do this but it's a pretty large undertaking, it involves completely standardizing, codifying and reingineering the klik system. However, then each distribution can write macros that are specific to them and you don't have to put platform specific code into the the recipie.

That is bring up another question: how much infrastructure should be on target computer when it trying to handle klik: link. If recipe will be macro, then there should be some sort of package manager installed already on computer which can process incoming recipe into instructions like: get this file, register some mime type handler, etc, etc.. That is not bad, but it is more difficult task. And it is require much more specifications, definitions, etc..

Of course, it is more work, but consider what would happen if we use kommander scripts as MACROs that can be leveraged within recipies for KDE applications. We could very well have nice installers/uninstallers for applications.

dmiceman
09-18-2005, 10:38 PM
Of course, it is more work, but consider what would happen if we use kommander scripts as MACROs that can be leveraged within recipies for KDE applications. We could very well have nice installers/uninstallers for applications.

Ouch.. kommander is too bid dependency in my humble opinion.

sheldonl
09-18-2005, 11:26 PM
Of course, it is more work, but consider what would happen if we use kommander scripts as MACROs that can be leveraged within recipies for KDE applications. We could very well have nice installers/uninstallers for applications.

Ouch.. kommander is too bid dependency in my humble opinion.

That of course would only be for KDE applications, but doesn't have to be there, just some ideas.

probono
09-19-2005, 12:36 PM
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
09-19-2005, 10:18 PM
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
09-20-2005, 08:40 PM
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
09-21-2005, 09:30 AM
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
09-23-2005, 03:57 PM
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
09-23-2005, 06:01 PM
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
09-24-2005, 06:44 PM
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
09-25-2005, 12:43 AM
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