Menus

[Pete Ryland]

On 26/10/06, The Rasterman Carsten Haitzler <raster at rasterman.com> wrote:
>
> the spec - especially the icon finding pats, are atrocious when it comes
> to
> overhead. the hoops  then end up needing to get jumped through for
> speedups are
> nasty. :(


Well, the spec was written a while ago.  It's not the only spec in the world
that could be better in hindsight!

know what icons have a Source= and Original= line so we can keep a list of
> these
> (mots likely a short one) and just in the background every few seconds or
> minute or whatever poll each file in the "personally modified .desktop
> files"
> list and see if the modified time of Source changes (or md5sum or just
> compare
> directly to our Original copy). yes - keep a COPY of the Original too -
> only
> for .desktops that the user modifies though. this is an expense of 1 extra
> file
> for the modified copy (so a private .desktop copied from the original then
> with entries changed/added/deleted as desired by the user and a pristine
> original copy just in case the source goes awol or changes so we can
> figure
> out what changed without having to turn the user's modified copy into what
> is
> effectively a unified diff and thus have to change a lot of .desktop
> parsing/handling in a lot of apps). since we have this - we can compare it
> to
> the new "source" that has been installed and see if anything has changed
> - if it has the upstream changed and we can figure out what and provide
> all the
> information if needed to the user and present options as to what to do (or
> just
> try and do it automatically). this should work universally with anything
> you
> feel like changing and not change parsing semantics of a .desktop file for
> older
> implementations as it is just an extension to the current format.
>
> > Actually, I think users will be ok with having a menu item not get
> updated
> > if they've changed anything like the name or parameters, in fact this is
> > probably what they want.  However, if all they've done is unhide the
> item, I
> > think they'd want system updates to apply.  If the file name changes, I
> > don't think it's a problem for a user to have to unhide it again;
> there's
> > really nothing else possible, but the old one item should no longer
> appear.
> > Perhaps we need another file which simply contains the hidden status, or
> put
> > this in the .menu file instead.
>
> the problem with this is - it only handles this situation with 1 property.
> it's
> a very limited solution which should be able to apply to any property (use
> only
> changed the icon but wants everything else to be inherited/stay the same.
> user
> only changed the name (label) because it was too long but wants everything
> else
> to stay the same and be inherited). the same problem as with hidden
> properties.


You're right, the user would probably want this for all properties.

I might have to have a go at implementing this three-file method then in
gnome-menus (probably next weekend or the weekend after if I'm not busy) so
I'll let you know how it goes!

Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061029/69ed14a9/attachment.htm