[prev in list] [next in list] [prev in thread] [next in thread] 

List:       klik-devel
Subject:    [klik-devel] Suggestions for klik development
From:       k1pfeifle () gmx ! net (Kurt Pfeifle)
Date:       2005-10-29 23:59:31
Message-ID: 200510300059.32393.k1pfeifle () gmx ! net
[Download RAW message or body]

First of all, it is great to see the progress Jason has made with his
Gnome and KDE "thumbnailer" (allows to display app-specific icons
with each klik.cmg).

You all have probably taken note of Kernel 2.6.14 sporting FUSE
support, too. ;-)

I'd like to hear your comments about my thoughts about what do do
next for klik's development. I didnt have time to come up with some
systematic structuring of my ideas. So this is a somehow wild
enumeration of various thoughts:

  * klik needs a clearer "profile" about the applications it offers.
    Currently, any newbie klik user visiting the website is
    overwhelmed (and initially greately impressed) by the huge number
    of apps that he can klik. And he'll of course try with what his
    personally mostly wanted program is -- and very frequently this
    may be one that he couldnt get to work from his system package.
    So the auto-generated klik recipes are bound to have problems in
    running successfully. Hence, klik's website should first and
    foremost display 100-200 well-working, and well-tested recipes
    (known to work on all supported distros). These 100-200 apps
    should have active maintainers. These apps should also be tagged
    as "works well with klik". All other 4000+ packages should be
    "hidden" one more click away, behind a link "More packages,
    currently beta -- but you can help testing!" I think users get
    frustrated with klik more often than needs to be -- and by
    seducing users to first try a bundle that is known to work, this
    frustration can be minimized. (I believe probono has already
    started on some of these ideas -- and an initial web interface to
    let recipe maintainers fix packages is already in place).

  * various klik packages do not cleanly umount after shutting them
    down. Processes keep running. Mountpoints stay occupied. Future
    startups or other packages may fail therefor. I think, we could
    possibly fix that with some additional code in .zAppRun: it
    should look (with the help of "lsof") if there are still
    processes running that access files underneath the mountpoint,
    and if so, kill them. Do this in a loop that does at least 3
    attempts, with 2-3 sec "sleep"s in between, before giving up.
    Display a warning dialog to the user if it doesnt succeed.

  * due to the high level of integration into the KDE environment
    (which we all love, right?), klik-ified KDE apps have to struggle
    with some disadvantages: they do not display their own help files
    (even if they may be bundled with the .cmg) since KDE usually
    calls its khelpcenter and help:/ KIO slave subsystem to display
    application manuals. And these systems just do not know about
    klik, and stubbornly offer the system-wide installed manuals (or
    non at all) if a user selects "Help" from the klik app's menu. A
    not-so-clean approach to overcome this could be to set some very
    specific environment variables (KDETMP=/tmp/klik-$USER, KDEVARTMP
    =/tmp/klik-$USER/var, KDEHOME=$HOME/.kdeklik, KDESYCOCA=$HOME
    /.kdeklik/ksycoca, KDEDIRS, KDE_LANG, KDE_FORK_SLAVES...) and
    call kbuildsycoca to create a separate KDE System Cache for the
    KDE klik apps. Disadvantage is extended startup time, and
    potential interference with the users standard icon/menu setup
    managed by the default kded/kbuildsycoca processes. This is under
    further investigation by me.

  * we should introduce a ".klikrc" configuration file. This file
    would be read by .klik, .zAppRun (and maybe even by each wrapper)
    for certain custom settings. (Of course. if not present, klik
    would still work, like now, and use some sane defaults). In
    .klikrc we could specify certain environment variables and other
    stuff to override default behaviours. It could also be a place to
    tell the klik server: "Look, I have libXinerama and libstdc++5
    installed -- no need to include them in my recipe!". -- Thankfully, 
    probono already has accepted my suggestion for a "KLIK_MAINTENANCE" 
    env var; if set to "yes" this will not remove the input/ingredient 
    files from the /tmp/klik/$APPNAME/ staging directory, and hence 
    simplify recipe maintainers jobs (no need to re-fetch files all 
    the time while testing variations of a recipe locally, etc.)

  * the wrapper should be refactored to completely use shell
    functions (and recipe and install, and hence .klik and .zAppRun
    too). This will allow for a more flexible recipe generation (per
    package, per distro, per package category). It also lends itself
    to more modular debugging, testing, modifying things. It could
    enable us to set up a "function test suite" for each newly
    supported distro. It would also make easier the insertion of
    specific functions at certain places in the recipe. To give an
    example: for the klik://koffice-nightly package, I'd like to
    start Konqueror with a specific help file describing the current
    stage of KOffice development. Of course, I can create a
    completely customized wrapper for that package -- however, I'd
    like to see a more generic mechanism to achieve that, because it
    will be useful for many more purposes also. I can come up with a
    first implementation maybe tomorrow evening.


OK, that's it for now. Please give me your thoughts about it.

If you can quickly agree to the refactoring of the wrapper at least
(install, .klik and .zAppRun can be postponed), I'll try to prepare a
first implementation by tomorrow evening.

Cheers,
Kurt



[prev in list] [next in list] [prev in thread] [next in thread]