On 26/10/06, <b class="gmail_sendername">The Rasterman Carsten Haitzler</b> <<a href="mailto:raster@rasterman.com">raster@rasterman.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, 26 Oct 2006 02:41:08 +0100 "Pete Ryland" <<a href="mailto:pdr@pdr.cx">pdr@pdr.cx</a>> babbled:<br>> 1. User installs package XYZ (which has nodisplay=true in xyz.desktop, so<br>> doesn't show up in the menus by default)
<br>> 2. User runs a menu editor and sets it to display, causing the menu editor<br>> to copy the .desktop file to ~/.menus/ with nodisplay=false<br>> 3. User upgrades package XYZ which has changed its binary's name to xyz2
<br>> 4. User's menu has now broken<br><br>aaah a COW problem (can of worms). - problem - what if app now changes<br>its .desktop name from gimp.desktop to gimp-2.2.desktop in the upgrade (has<br>happened before)? back to same/similar problem. and include doesn't fix it.
<br>thought useful - this also adds more expense and slowness and disk io overhead<br>in parsing .desktop files.</blockquote><div><br>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 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).
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">in reality the problem is that of shadowing data you<br>can't always monitor and know what happened to it - did it get deleted, simply
<br>upgraded to a new name etc. etc.<br><br>i think that maybe this is a problem we can live with - but if we absolutely<br>have to have a fix, maybe instead of an include we have a Source= line added<br>that determines the real source - at any time the menu or launcher or whatever
<br>can perform a sanity check and find the source that this .desktop shadows and<br>then infer if it has changed and alert the user to take some action. Maybe also<br>an Original= line that points to a pristine copy of the source before the
<br>shadow copy (in the users config) was altered. thus no matter what happens to<br>the original itself, other than deletion of the file, the app can infer what,<br>changed in the original compared to when it made the shadow copy and what has
<br>been altered in the shadow compare to that original.</blockquote><div><br>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.
<br></div><div><br>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.
<br><br>Pete<br></div></div>