[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: RFC: new KPanel application menu
From: iglio () fub ! it (Pietro Iglio)
Date: 1999-07-13 8:35:46
[Download RAW message or body]
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.
Comments and criticisms will be appreciated.
-- Pietro Iglio
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic