Created attachment 259940 [details] [review]
Add g_desktop_app_info_get_implementors()

This provides support for the draft addition of 'Implements=' to the Desktop
Entry specification.

Created attachment 259941 [details] [review]
docs: add two missing symbols on GDesktopAppInfo

Created attachment 259942 [details] [review]
tests: add tests for GDesktopAppInfo Implements=

Review of attachment 259940 [details] [review]:

::: gio/gdesktopappinfo.c
@@ +3541,3 @@
+ *
+ * An application implements an interface if that interface is listed in
+ * the Implements= line of the desktop file of the application.

That explanation is a bit disingenuous, I think.

We are talking about D-Bus interfaces on the session bus here, right ?

Review of attachment 259942 [details] [review]:

The first patch implies that you plan to make Implements a string list key. The syntax for those in the desktop entry spec requires a terminating ;
All your examples here are invalid. Also would be good to add a testcase with more than one interface.

(In reply to comment #4)
> ::: gio/gdesktopappinfo.c
> That explanation is a bit disingenuous, I think.
> 
> We are talking about D-Bus interfaces on the session bus here, right ?

No.  It's actually entirely up to the person implementing the interface to define what it means to implement it.  We could easily imagine certain interfaces defined in terms of executing the Exec line with an an additional parameter.  We define only these guidelines:

 - probably this is a DBus interface on the session bus

 - if so, the app should be DBusActivatable

 - probably the interface is on the same object path as the application

 - if you want to give more details regarding how the interface is implemented
   (ie: change object path, or something else) then you should use a group in
   the desktop file with the same name (eg: [org.my.interface]) to describe it

Jasper had a patch to the spec for a while to add this language but I don't think he ever filed a bug, and I didn't like the way he had written it, so it never went anywhere.  I'm going to try again for myself.

(In reply to comment #5)
> syntax for those in the desktop entry spec requires a terminating ;
> All your examples here are invalid. Also would be good to add a testcase with
> more than one interface.

Good catch.  Will fix this, thanks.

(In reply to comment #6)
> (In reply to comment #4)
> > ::: gio/gdesktopappinfo.c
> > That explanation is a bit disingenuous, I think.
> > 
> > We are talking about D-Bus interfaces on the session bus here, right ?
> 
> No.  It's actually entirely up to the person implementing the interface to
> define what it means to implement it.  We could easily imagine certain
> interfaces defined in terms of executing the Exec line with an an additional
> parameter.  We define only these guidelines:
> 
>  - probably this is a DBus interface on the session bus
> 
>  - if so, the app should be DBusActivatable
> 
>  - probably the interface is on the same object path as the application
> 
>  - if you want to give more details regarding how the interface is implemented
>    (ie: change object path, or something else) then you should use a group in
>    the desktop file with the same name (eg: [org.my.interface]) to describe it

Can't say I like this much - why not make it concrete, and say

ImplementsDBusInterface=

That would be much more useful, and leave much less room for things to go wrong.

(In reply to comment #7)
> ImplementsDBusInterface=
> 
> That would be much more useful, and leave much less room for things to go
> wrong.

Because I specifically want to leave it up to people who define interfaces as to exactly what it means to do so.  People will try to do it anyway -- we may as well embrace it from the start.  Even if we somehow enforced that you absolutely must actually implement such a DBus interface at a given path, people may just wind up having a trivial implementation with some sidechannel to do what they wanted in the first place.

That said, I suspect that most people really will use D-Bus for this and the interface name will be equal to the D-Bus interface name.  I just don't see the need to hardcode it.

But an interface is only useful if it is clear how to use it to... interface with.

Having some fluffy

Implements=mysterious-ipc-interface

does not do anybody any good. Because you'll need an extra

HeresTheCommunicationChannelToUse=

anyway.

I really don't get it. What other use case do you have ?

(In reply to comment #9)
> But an interface is only useful if it is clear how to use it to... interface
> with.

And how do you know how to do that?  It's already different per-interface.  There's no universal org.freedesktop.[interfacenamehere].DoSomethingUseful DBus call...  It's only meaningful in the first place to be looking up implementors of a particular interface if you will know what to do with the implementation once you get it.


> does not do anybody any good. Because you'll need an extra
> 
> HeresTheCommunicationChannelToUse=

As mentioned above, any extra information required by a particular interface would go into a group with the same name as the interface.

> I really don't get it. What other use case do you have ?

At the desktop summit, the razor-qt guys were interested in using this mechanism to do something with Exec= lines.  I don't remember exactly.

I guess we just have a different perspective on what this keys main purpose is.

You look at it as an univeral hook into your desktop file index. Need some subset of desktop files searchable ? just add Implements=foobar, and, voila!, the index will spit them out. We could as well call it SearchKeys=

I'll retract my opposition to this - having a SearchKeys field is useful, even if it is called Implements.

Attachment 259941 [details] pushed as 0b27719 - docs: add two missing symbols on GDesktopAppInfo
Attachment 259942 [details] pushed as 880e8e8 - tests: add tests for GDesktopAppInfo Implements=