From kde-devel  Tue Jul 13 08:35:46 1999
From: iglio () fub ! it (Pietro Iglio)
Date: Tue, 13 Jul 1999 08:35:46 +0000
To: kde-devel
Subject: RFC: new KPanel application menu
X-MARC-Message: https://marc.info/?l=kde-devel&m=93185497813845

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