On 26/10/06, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> 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
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg

Reply via email to