[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic