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

List:       kde-devel
Subject:    Re: RFC: new KPanel application menu
From:       iglio () fub ! it (Pietro Iglio)
Date:       1999-07-23 11:27:30
[Download RAW message or body]

At 11.34 23/07/99 +0200, Waldo Bastian wrote:
>The latest idea was to seperate the contents of .kdelnk (now .desktop) files
>and the location in the menu. Basically we would then just have a (menurc)
file which describes which entries should show up where in the menu.
>
>Your mail made me realize that this has a disadvantage. When a new
application
>gets added to the system, this will most likely not show up in any user menu
>since the user will have its own menurc file which will override the system
>one. 
>
>Your solution with a link to the original position and a "Removed from" line
>seems to be pretty smart. Together with KStdDirs it will be very easy for
>KPanel to implement things:
> ...
>
>Pietro: Do you think this still feasible or have you already implemented
>it the other way? This seems to work very smart. readDesktopFile should
>just read the desktop file in the "shadowing" fashion we talked about
>earlier on.

I think that the described solution of having desktop files pointing to
other desktop files (if I have understood correctly) should be discarded.

I'm already implementing the menurc stuff, and I've already tought about the
problem of new entries in any non-local menu: kpanel will have a file-watch
mechanism to detect changes to any non-local menu. As soon as this happen,
kpanel invokes the merging algorithm I have written and will compute again
the set of applications listed in the menu.

It seems to work so far and does not require to add any extra field to the
.desktop files.

-- Pietro

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