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

List:       kde-devel
Subject:    Re: RFC: new KPanel application menu
From:       Stephan Kulow <coolo () max ! tat ! physik ! uni-tuebingen ! de>
Date:       1999-07-13 10:35:35
[Download RAW message or body]

Pietro Iglio wrote:
> 
> 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.
How can it confuse users if they can only see their menu and can change
everything? 
> 
> 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.
Well, I think, copying these files is _completly_ unacceptable. In our
university (just as an example) we have 380 users. My current
KDEDIR/share/apps
has 291 kbyte in 167 files (wow - there aren't even core files :). This
would
mean 110MByte just that the user sees the global entries. 
> 
> >If you think it is hard to do this with the current implementation
> >of kstddirs I will be happy to provide additional functionality.
> 
> OK.
I can't see how this would be harder. I think, Waldo already proposed a
way to handle this.

Greetings, Stephan

-- 
As long as Linux remains a religion of freeware fanatics,
Microsoft have nothing to worry about.  
                       By Michael Surkan, PC Week Online

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