On Thu, 26 Oct 2006 16:38:38 +0100 "Pete Ryland" <[EMAIL PROTECTED]> babbled:
> On 26/10/06, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > > > > On Thu, 26 Oct 2006 02:41:08 +0100 "Pete Ryland" <[EMAIL PROTECTED]> > > babbled: > > > 1. User installs package XYZ (which has nodisplay=true in xyz.desktop, > > so > > > doesn't show up in the menus by default) > > > 2. User runs a menu editor and sets it to display, causing the menu > > editor > > > to copy the .desktop file to ~/.menus/ with nodisplay=false > > > 3. User upgrades package XYZ which has changed its binary's name to xyz2 > > > 4. User's menu has now broken > > > > aaah a COW problem (can of worms). - problem - what if app now changes > > its .desktop name from gimp.desktop to gimp-2.2.desktop in the upgrade > > (has > > happened before)? back to same/similar problem. and include doesn't fix > > it. > > thought useful - this also adds more expense and slowness and disk io > > overhead > > in parsing .desktop files. > > > There is actually no extra disk io overhead, since both .desktop files will > be parsed anyway (well at least that's currently what happens in the gnome ours would avoid it... :) > implementation). Besides, this would be a relatively tiny extra overhead. > There are far greater inefficiencies in other ways in gnome-menus in any > case (I'm not familiar with other implementations of this spec). 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. :( > in reality the problem is that of shadowing data you > > can't always monitor and know what happened to it - did it get deleted, > > simply > > upgraded to a new name etc. etc. > > > > i think that maybe this is a problem we can live with - but if we > > absolutely > > have to have a fix, maybe instead of an include we have a Source= line > > added > > that determines the real source - at any time the menu or launcher or > > whatever > > can perform a sanity check and find the source that this .desktop shadows > > and > > then infer if it has changed and alert the user to take some action. Maybe > > also > > an Original= line that points to a pristine copy of the source before the > > shadow copy (in the users config) was altered. thus no matter what happens > > to > > the original itself, other than deletion of the file, the app can infer > > what, > > changed in the original compared to when it made the shadow copy and what > > has > > been altered in the shadow compare to that original. > > > This does seem a better approach, but I can see two drawbacks already. > Firstly, when would the user be prompted to take action on a changed > original? In the menu editor? When using the panel's menu, or any other > menu consumer? Secondly, how can you determine if the original has > changed? Are you suggesting keeping a copy of the original system .desktop > file alongside the user's file and comparing it every time to the current > system file? Surely there's a better way. that's up to the implementation. for us - we load it all on startup. since we are a wm - we need things like the class properties, icon info etc. to match up with windows to stick the right icon there - and more. we jump through a few hoops to keep loading up every .desktop you have in the sub-second range. haven't done caches yet... that's next. :) but for us - we would be able to detect on login/start and then put up a nice "hey - by the way... app X has changed in a way i can't fix for you.. would you like to...". while up - we 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. > Pete > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
