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

List:       kde-devel
Subject:    Re: RFC: new KPanel application menu
From:       iglio () fub ! it (Pietro Iglio)
Date:       1999-07-13 10:23:35
[Download RAW message or body]

At 11.57 13/07/99 +0200, Waldo Bastian <bastian@ens.ascom.ch> wrote:
>Pietro Iglio wrote:
> 
>> Note that I'm not considering any other directory layer, such 
>> as the "group" layer suggested by Stephan because (a) the
>> implementation would be much harder and (b) more than two 
>> layers can be too confusing for users and administrators.
>> 
>> Comments and criticisms will be appreciated.
>
>First of all I like it very much.
>
>Some small points:
>
>$HOME/.kde and $KDEDIR don't exist any more in KDE 2.0. 
>
>Instead of $HOME/.kde you should use 'locateLocal()' to find
>the location where to store stuff. By default this will be
>$HOME/.kde but you can't count on it.
>
>$KDEDIR doesn't exist any more either. Instead the user can 
>provide a ordered list of directories which to check. When 
>searching for resources, the most 'specific' directory is
>looked up first.
>
>For kpanel I suggest to use for 'publishing' the 
>"least specific directory the user can write to".
>
>Example:
>It he user has 
>KDEDIRS="/opt/kde:/usr/local/kde:/home/department/.kde:$HOME/.kde"
>
>Then the "most specific" directory is "$HOME/.kde"
>the "least specific" directory is "/opt/kde".
>
>When the user has write access to /usr/local/kde,
>/home/department/.kde and $HOME/.kde
>publishing the application will write it to /usr/local/kde.

In principle, I agree with you. Your approach would also be
more complete, because you can publish at any level (eg. local,
workgroup, all users).

In practice, however, I think that more than two levels can confuse 
users. Two levels (personal/global) looks like a right trade-off 
between flexibility and simplicity. Thus I'm suggesting, at least for
applications, to keep the old, two-levels model.

This is a personal opinion. A more objective problem is that the
implementation with n-layers would be, at a glance, harder than the
one proposed. I have to think about that.

>If you think it is hard to do this with the current implementation 
>of kstddirs I will be happy to provide additional functionality.

OK.

-- Pietro

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