[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:27:33
[Download RAW message or body]

Pietro Iglio wrote:
> 
> I'm thinking about an alternative way to generate the application menu in
> kpanel. The idea is to unify the global and personal menus and to allow
> full user customization.
> 
> Here are the requirements:
> 
> - there is a single application menu (no personal/global);
> 
> - the user can completely customize his/her menu without any extra privilege;
>   by customizing I mean: it is possible to change item properties (icon,
>   name, etc.), move an item, delete an item, add a new item, create/remove
>   folders;
> 
> - privileged users (= user with write access in $KDEDIR/share/applnk) can
>   publish items; published items will be visible in all users menu;
> 
> In my opinion this is the most flexible implementation. From the user point
> of view, there no need to accept the concept that some entries can be changed
> by the administrator and other entries by the user itself. This is confusing
> for users coming from single-user environments (Win95/98).
> 
> How this is implemented:
> 
> - the application menu structure is completely stored in
>   $HOME/.kde/share/applnk;
> 
> - when a new application is published to all users, it is stored in
>   $KDEDIR/share/applnk;
> 
> - when (eg) $HOME/.kde/share/applnk/Utilities is built, kpanel looks in
>   $KDEDIR/share/applnk/Utilities for new entries; new entries can
>   be detected comparing each .desktop file creation date with the date
>   stored in $HOME/.kde/share/applnk/Utilities/.directory:
> 
>      MostRecentEntry=Konsole.desktop,99/05/02
> 
>   Suppose that a newer entry KEditor.desktop is found. Then, it is
>   copied in $HOME/.kde/share/applnk/Utilities and the following entry
>   is added to $HOME/.kde/share/applnk/Utilities/KEditor.desktop:
> 
>       Origin=Utilities/KEditor.desktop
> 
>   The "Origin" key is used to keep track of the originating item. If,
>   for example, the user moves Utilities/KEditor.desktop into
>   Utils/KEdit.desktop and $KDEDIR/share/applnk/Utilities/KEditor.desktop
>   is removed, it will be easy to remove the item from the user private
>   menu.
> 
> - when the user changes any item property (eg. its icon), changes are stored
>   in the local copy.
> 
> - when the user removes an entry, the local copy is removed;
> 
> - when a user with write permission in the global dir creates a new app,
>   it is possible to click on a "Publish" checkbox to copy the item into
>   the global dir, so that all users will "see" the new app.
> 
> With the described approach, the user can do everything he/she likes.
> I think that this approach is superior, for example, to the WinNT
> approach.
> 
> 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.
> 
There is no such "group" layer. It's just that there is no global
directory
for KDE anymore. All you have are
findResource/findResourceDir/findAllResources
within KStandardDirs. 

I want to remove kde_appsdir and localkdedir and I will.

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]