On Thu, 26 Oct 2006 02:41:08 +0100 "Pete Ryland" <[EMAIL PROTECTED]> babbled:
> Hi, > > I've noticed a bit of a shortcoming in the menu specification. It seems > there's no way for a menu editor to provide menus that override parts of a > .desktop file, like say the "no display" attribute, without copying the > complete .desktop file to the user's menu directory. This seems a bit > strange to me, since it would seem to be a pretty common case. The problem > comes in the following instance: > > 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. 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. it can apply the same changes to the new original and make a new shadow, if those changes trivially apply. if not it can prompt the user to intervene and make a choice. you still have a problem of if the source went away (got renamed to gimp-2.2.desktop for example) as you don't have a trail to follow to the new filename - but the implementation can suggest that the app has been removed and the user should ok removal of the shadow - they now need to modify the new .desktop and make a new shadow copy etc. > This could be fixed by changing either the .menu spec, allowing overrides to > be placed there, perhaps as an attribute to <Include>, or by changing the > .desktop spec to allow files like this: > > [Desktop Entry] > Inherits=true > NoDisplay=false > > which would then inherit all other properties from any previous file with > the same desktop id. > > The big downside to this is that all properties now have to be Optional, and > this could cause even more trouble. So there's probably a better solution > out there that doesn't suffer from this problem. > > 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
