[RFC] A trivial change for DESKTOP_ENTRIES (take 2)

[Jung-uk Kim]

On Thursday 14 July 2011 01:54 pm, Pav Lucistnik wrote:
> Stephen Montgomery-Smith p紫e v �t 14. 07. 2011 v 11:57 -0500:
> > entry.  I assume that the filename of the desktop entry is
> > unimportant,
>
> The filename of desktop entry should be 100% inconsequential, and
> our only care should be not have two ports installing same file.

I believe the original intention was to use executable name to make 
desktop file, i.e., ${PREFIX}/bin/foo -> ${DESKTOPDIR}/foo.desktop.  
I understand your concerns but we only have to worry about two ports 
installing executables with a same name in two different directories 
and both having DESKTOP_ENTRIES.  I haven't seen such ports from our 
ports tree.  If there is, it should be fixed individually.  Or we may 
have to consider something totally radical.

> > and is used only internally by Gnome or whatever.
>
> Sounds like a bug to me.

Why do you think there is a bug?  Basically, desktop files are 
meta-data for OSes which cannot handle extended attributes within a 
file (e.g., resource fork of Mac), if I understand it correctly.  I 
don't see anything wrong with GNOME referencing its window manager by 
desktop file name rather than by executable name with obscure 
options.

> > But maybe it would have been better to have had one more entry in
> > DESKTOP_ENTRIES that was the actual filename of the desktop
> > entry.
>
> Yes, but is it worth the effort? Note you'll have to introduce it
> somehow not to break existing ports.

DESKTOP_ENTRIES are for *basic* stuff and bsd.port.mk clearly says 
complex desktop files cannot use it:

Rules:
* Only add desktop entries for applications which do not
  require a terminal (ie. X applications).
* If the upstream distribution already installs .desktop
  files, you do not need to use this.
* If you require a more elaborate .desktop file than this
  variable permits, write it yourself and install it
  in ${DESKTOPDIR}.

The actual bug for bsd.port.mk was that it did not mention field 4 
Exec cannot contain '/' or any options, IMHO.

Jung-uk Kim