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

Originally Posted by probono

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/documenta...hdiutil.1.html

Greetings,
probono

**dmiceman** · 09-18-2005, 08:02 PM

Originally Posted by probono

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.

Originally Posted by probono

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/documenta...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

Originally Posted by sheldonl

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

Originally Posted by dmiceman

Originally Posted by sheldonl

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

Originally Posted by sheldonl

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

Originally Posted by dmiceman

Originally Posted by sheldonl

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.