[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 13:53:16
[Download RAW message or body]

At 15.39 23/07/99 +0200, you wrote:
>Pietro Iglio wrote:
>> 
>> I think that the described solution of having desktop files pointing to
>> other desktop files (if I have understood correctly) should be discarded.
>
>I agree. The rc file concept promises to
>
>a) be faster (when parsing)
>b) save space
>c) offer more flexibility (sorting order etc.) without touching the
>format of .desktop files each time we need a new feature.

Right.

>> 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.
>
>What kind of file-watch are you thinking of. Another real-time one ? How
>about calculating a checksum of the watched directories and recompute
>the local structure if the checksum is broken to a modification in the
>global setup.

When the menu Utilities is displayed, and every n seconds until it is still 
displayed, check the modification date of:

/opt/kde/.../kpanel/menu/Utilities/menurc
... (any intermediate level)
~/.kde/.../kpanel/menu/Utilities/menurc

Yes, a date-checksum could save storing each file modification date.
May be a class KFilesWatch(), similar to KDirWatch, could be useful in
the library.

-- Pietro

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