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

List:       kde-devel
Subject:    Re: RFC: new KPanel application menu
From:       "Dirk A. Mueller" <dmuell () gmx ! net>
Date:       1999-07-13 16:11:30
[Download RAW message or body]

iglio@fub.it (Pietro Iglio) wrote:

> - there is a single application menu (no personal/global);

very good, I like this.

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

right! a must be.

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

which blows it up. might be a problem for people who have very low
quota's. At university here a student has 5MB quota for home, which
isn't very much.

>   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

this breaks when a user configures its menu by manually moving the
files around. shell scripts tend to do that.

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

I like the ideas behind, I don't like the way you suggested the
implementation, however I currently can't think of a better way doing
it. Let me think about it a while.

> Comments and criticisms will be appreciated.

KStdDirs can be a big helper with implementing this, as it
automatically first looks for a file in the local paths and then later
in the global one.

so the whole maintaining load can be moved to KStdDirs. the new api is
really clever, it also allows more levels than just global/local, which
is a very cool feature.

Maybe you should first take a look at locate() and locatelocal() and
then re-think about the implementation.

maybe a separate configfile would help, which also reduces the number
of directory parsings necessary for building a panel menu (I don't like
the current situation, the parsing is just to slow and can't be
optimized the way it is implemented now). then you can easily add
entries like "Deleted=<path>/file" and "moved=<originalpath>,<newpath>"
and something like that.

take a look on how i.e. icewm stores it's menu. simple and very fast.
maybe we can copy some of the ideas behind that.

Lets think about an implementation that both enables your mentioned
features (no need to discuss them, they're great!) _and_ speeds up the
building of a panel menu.


-- 
Dirk A. Mueller

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