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

List:       kde-devel
Subject:    Re: RFC: new KPanel application menu
From:       John Corey <whoop () mtco ! com>
Date:       1999-07-13 15:51:13
[Download RAW message or body]

Robert Hagemann wrote:
> 
> Hi,
> 
> <cite>
> 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.
> </cite>

You're missing the point of KStandardDirs.  We have one system that can
have 1, 2, 3, or 18,430 directory structures.  If a distribution only
has the usual two, then that's fine and all applications that use KSD
will work just fine.  Users will not even have to think about it if they
are in an environment with several layers.  If they modify anything, it
goes in their ~/.kde.

> I'd rather think, it isn't too unlikely to have more than 2 levels. In my
> former university there was
> some kind of application-profiles. That means, the user could choose to
> have the account
> configured as Tex-User, Matlab-User, Smalltalk-Programmeer whatsoever. My
> suggestion is
> to provide some similar mechanism through group levels. You have some
> global directory,
> some application-profile related directory und the private one. The user
> chooses / is configured
> to be member of some application group(s). As a result he/she sees the
> merges from more than 2 levels.

All a sys admin would have to do is add the necessary directories to a
new user's KDEDIRS environment variable.  And then when the user logs
on, just like magic if they are a math major, they get Matlab and
related programs in the menu.  If they're a computer science major, they
get programming tools.  And so on.  And still, the user doesn't even
need to know about this, any changes get dumped in their private .kde
directory.

More importantly, application developers don't even have to think about
this.  They just use the KStandardDirs functions, KConfig, etc and it
all just works.  These classes search for files first in their personal
dir, then department dir, finally a global dir (based on the ordering of
KDEDIRS).

Of course, this is only the case when that moment of utopia is reached
and everything uses the right API...

> Just my two coins,
> 
> ciao,
> Robert
> .

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