[mpris] DesktopEntry shortcomings

[Lennart Poettering]

On Thu, 23.12.10 14:39, Alex Merry (kde at randomguy3.me.uk) wrote:

> On Wednesday 22 December 2010 17:29:32 Conor Curran wrote:
> > Why shouldn't it be the full path to the desktop file including the
> > extension ?
> 
> For backwards compatibility purposes, I'd rather add a DesktopFilePath 
> property that operates as Conor suggests, and deprecate DesktopEntry.
> 
> Would anyone object to me including this in 2.1?

Yes. I would.

What's hte alue of changing this?

Whether the name is suffixed with .desktop doesn't really matter. It's
trivial to convert one form to the other, and there is no point at all
to introduce another property with the suffix added.

The search path for .desktop filse is pretty clear:
$XDG_DATA_DIRS/applications/ (defined in the desktop entry spec). This
is where .desktop files should be placed and we are well advised leaving
the lookup to the cliet side apps, so that it can apply the necessary
rules and people don't ever get the idea to specify a .desktop file htat
is specific to MPRIS but otherwise undiscoverable. To make it easy for
desktop environments to match up MPRIS services, windows and
"applications" it is essential that these objects refer to the name of a
desktop file, instead of an explicit desktop file path.

What would the benefit be of storing the full path in the properties? That
it is easier for the client side to read the .desktop file? That would
be really broken, as properly handling .desktop files isn't as trivial
as people might think and they should never roll anything for this on
their own, but use the standard implementations of the XDG basedir
spec/XDG desktop entry spec that is available in all DE API frameworks.

So, in summary: it's a bad idea to change this. Don't do it.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.