Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: Ideas on klik evolution

  1. #1

    Ideas on klik evolution

    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.

  2. #2
    Senior Member registered user
    Join Date
    Feb 2003
    Location
    Germany
    Posts
    1,159
    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

  3. #3
    Junior Member registered user
    Join Date
    Sep 2005
    Posts
    12
    Quote 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.

  4. #4
    Senior Member registered user
    Join Date
    Feb 2003
    Location
    Germany
    Posts
    1,159
    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

  5. #5
    Junior Member registered user
    Join Date
    Sep 2005
    Posts
    12
    Quote 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.

    Quote 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.

  6. #6

    Update on the kio thingy

    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.

  7. #7
    Junior Member registered user
    Join Date
    Sep 2005
    Posts
    12

    Re: Update on the kio thingy

    Quote 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..

  8. #8

    Re: Update on the kio thingy

    Quote Originally Posted by dmiceman
    Quote 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.

  9. #9
    Junior Member registered user
    Join Date
    Sep 2005
    Posts
    12

    Re: Update on the kio thingy

    Quote 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.

  10. #10

    Re: Update on the kio thingy

    Quote Originally Posted by dmiceman
    Quote 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.

Page 1 of 2 12 LastLast

Similar Threads

  1. Some fresh ideas
    By vlader2004 in forum Ideas
    Replies: 1
    Last Post: 01-06-2005, 01:04 AM
  2. Samba ne ideas how to this??
    By pinku in forum Networking
    Replies: 0
    Last Post: 02-07-2004, 09:52 AM
  3. some ideas for knoppix
    By cloeser in forum Ideas
    Replies: 2
    Last Post: 10-03-2003, 10:50 AM
  4. few ideas
    By freeballer in forum Ideas
    Replies: 1
    Last Post: 02-20-2003, 10:07 PM
  5. Some new ideas!
    By Sanja in forum Ideas
    Replies: 26
    Last Post: 01-17-2003, 03:01 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •