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

List:       kde-devel
Subject:    Re: RFC: new KPanel application menu
From:       Waldo Bastian <bastian () ens ! ascom ! ch>
Date:       1999-07-13 10:47:11
[Download RAW message or body]

Hiya,

I missed some of the details I noticed:

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;

Yes, I fully agree with the requirments.

> In my opinion this is the most flexible implementation. 

<pedantic+>
No.. you were talking about requirements. The implentation follows.
<pedantic->

> How this is implemented:
> 
> - the application menu structure is completely stored in
>   $HOME/.kde/share/applnk;

I don't think this is a good idea. Why not use the global data
if it is available and only save changes here? (e.g. copy on write semantics)

> - when a new application is published to all users, it is stored in
>   $KDEDIR/share/applnk;

Well.. sort of (see my other comments)
 
> - 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.

I think this is way too kludgy. Why not make use of the cascading
directory structure kstddirs provide? Just use the 'most specific'
entry you encounter and have a flag in the .desktop files to
indicate that an entry is 'deleted'. The Origin field is nice.
I would store the complete path to the original .desktop
file there instead of just the group. 

You don't have to provide any additional info in the .desktop
file other than the Original .desktop file. The missing
information can be read from this original file. That way changes
made to e.g. the icon by root will affect the icon setting of
a user, even if he has moved the application to another group.
If he has changed the icon him/herself, the change will not 
affect him of course. (In this case the icon information is
in his local copy of the .desktop file)

> - 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;

And it will be added again once another application is published?
Why not create a .desktop entry for the application with a flag
indicating that the user doesn't want to see this application?

Cheers,
Waldo
-- 
The "gui" in "Penguin" is pronounced "K-D-E"

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