Is there anyone else from the summit who can review this patch?

After some reflection, I think that action parameters (as discussed at the sprint) should be included after all.  The reason for this is that a future notification specification that supports notifications persisting after an app has exited might use an action such as "show message" to wake the app up again (and then the parameter would be the message ID).

Yes, let's add action parameters.

About the patch:

* Docu for "Open" : "This method will only be called if the application has listed one or more MIME types."
Well that's true for application launchers, but surely an app launching another app (on a given URL) could use this method, even if the 2nd app doesn't list any mimetypes, just because the two apps know each other. I think this sentence should be removed, it describes a particular implementation (generic way of launching the associated app for a given file), rather than what the app developers should do when implementing the spec.

* Can you rename platform-data to platform_data everywhere, for the sake of Qt users? Arguments in 
https://codereview.qt-project.org/55360 aside, it would make life easier for Qt users trying to implement the spec, whether Qt is fixed later or not. Doesn't cost much on your side :)

* Last hunk: Exec is being made optional, but at the same time you say it should be written out for compatibility. Shouldn't we keep it required, then, for clarity and interoperability? I don't think anyone should ever assume that all implementations of the desktop entry standard will one day switch to the DBus method.



I'm surprised that you didn't post the patch to the xdg list before putting it up here, btw, to gather more feedback. At least post a link to this report there?

(In reply to comment #3)
> Well that's true for application launchers, but surely an app launching
> another app (on a given URL) could use this method, even if the 2nd app
> doesn't list any mimetypes, just because the two apps know each other.

Right.  This is an interesting case, and indeed for my (pending) implementation of the desktop action specification in GIO I include the possibility that you may invoke actions that are not advertised in the desktop file on the basis of "if the two apps know each other".

I think it would be useful to keep this wording out of the spec itself, though, and that's certainly in line with your request to delete that sentence.

I do want to be clear about this fact, though:

 - an app must handle Open if they have mime types in their desktop file
 
and I think this can go unsaid, but assumed true:

 - an app may choose to handle Open even if they don't have mime types in
   their desktop file, but Open will not be called by standards-comforming
   implementations used in the usual way, but could be called by other apps
   that know specifically that this app supports it.

> * Can you rename platform-data to platform_data everywhere, for the sake of
> Qt users?

Sure

> * Last hunk: Exec is being made optional, but at the same time you say it
> should be written out for compatibility. Shouldn't we keep it required,
> then, for clarity and interoperability? I don't think anyone should ever
> assume that all implementations of the desktop entry standard will one day
> switch to the DBus method.

I think it's very much possible that people who are making a particular device might indeed elect to do it this way.  That's why I prefer to keep the recommendation to have Exec= on the level of a recommendation.



I will upload a new patch soon.

+      For applications, the part of the name of the desktop file (before the <filename>.desktop</filename>)
+      should follow the "reverse DNS" convention, e.g. <literal>org.example.FooViewer.desktop</literal>.

This contradicts current practice, which is that desktop files' names are short strings resembling (but not necessarily matching) filenames in /usr/bin, or for that matter, systemd units.

As far as I'm aware, renaming existing .desktop files is pretty annoying, because the basename of the desktop file is commonly used as an identifier, so renaming it will break any existing associations. Is there consensus that this is worth doing, or is this intended to be  something that is only followed by new applications?

Is there any sort of aliasing mechanism that says "I used to be gnome-terminal.desktop"?

If we make applications and session services into systemd user services, what would the .service conventionally be called? At the moment, desktop files' basenames are essentially in the same conventional form as systemd services' basenames...

The main thrust of the renaming here is that we have too many different ways of referring to applications and we want to have only 1.  D-Bus well-known names seem like the most natural choice for that.

Being able to map a GApplication application ID or a well-known D-Bus name directly to a desktop file is pretty powerful...

I do think it's worth the fuss.

(In reply to comment #6)
> Being able to map a GApplication application ID or a well-known D-Bus name
> directly to a desktop file is pretty powerful...

D-Bus well-known names are case-sensitive, and are conventionally mixed-case. Desktop-file basenames treated as case-insensitive by at least GNOME Shell (see shell-app-system.c). Is this new naming convention case-sensitive or not?

(mpdris2 had to rename its desktop file from mpDris2 to mpdris2 to avoid showing up twice in the list of apps supporting notifications in GNOME 3.8...)

(In reply to comment #7)
> (mpdris2 had to rename its desktop file from mpDris2 to mpdris2 to avoid
> showing up twice in the list of apps supporting notifications in GNOME
> 3.8...)

Have you filed an upstream bug about this? This is entirely GNOME Shell's fault.

Created attachment 81915 [details] [review]
new patch

A new version of the patch with the following changes compared to before:

 - action parameter is added back

 - names in dbus interface now use underscores

 - sentence about open only being called if mimetypes are specified removed

 - changed wording suggesting that Exec= always be specified to be stronger
   and clearer

Looks good to me, approved.

Committed, then.  Thanks!