pdr at pdr.cx
Sun Oct 29 14:08:39 EET 2006
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
> 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
> (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
> list and see if the modified time of Source changes (or md5sum or just
> directly to our Original copy). yes - keep a COPY of the Original too -
> for .desktops that the user modifies though. this is an expense of 1 extra
> 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
> out what changed without having to turn the user's modified copy into what
> 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
> 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
> try and do it automatically). this should work universally with anything
> feel like changing and not change parsing semantics of a .desktop file for
> 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
> > 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;
> > really nothing else possible, but the old one item should no longer
> > Perhaps we need another file which simply contains the hidden status, or
> > this in the .menu file instead.
> the problem with this is - it only handles this situation with 1 property.
> a very limited solution which should be able to apply to any property (use
> changed the icon but wants everything else to be inherited/stay the same.
> only changed the name (label) because it was too long but wants everything
> to stay the same and be inherited). the same problem as with hidden
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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg