Menus

[Carsten Haitzler (The Rasterman)]

On Thu, 26 Oct 2006 02:41:08 +0100 "Pete Ryland" <pdr at pdr.cx> 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)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)