[PATCH weston 10/17] xdg-shell: Clarify the meaning of app ID and give example

[Pekka Paalanen]

On Tue, 7 Apr 2015 19:38:49 -0700
Bryce Harrington <bryce at osg.samsung.com> wrote:

> On Tue, Apr 07, 2015 at 07:12:48PM -0700, Jasper St. Pierre wrote:
> > It's described as murky because it is super murky.
> > 
> > In the brave new world, apps are supposed to be D-Bus Activatable.
> > That means setting DBusActivatable=true in their desktop file. A
> > requirement for this is that desktop file name needs to match their
> > bus name. D-Bus doesn't require this -- the desktop file specification
> > does.
> > 
> > If you don't follow that convention, you don't have one app ID you can
> > pass to this. You have multiple. In the X11 world, this includes your
> > resource and application class you set with the WM_CLASS property,
> > your Exec line / prgname, your bus name, your PID, and plenty more
> > (startup-notification ID, _GTK_APPLICATION_ID, your ICCCM window group
> > leader, X11 Client ID).
> > 
> > The best way to not be in that situation is to not be in it: you have
> > one app ID, and that's it. That's what I was trying to say in the
> > original specification.
> 
> That is good background, thanks.  Perhaps you could include some of this
> in the protocol description to help fill in the context.  And maybe
> reference to the desktop entry spec:
> 
>   http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus
> 
> There was also some discussion on the xdg list:
> 
>   http://lists.freedesktop.org/archives/xdg/2013-June/012828.html
>  
> > If you don't have that, there's no great answer for what to say your
> > ID is. GNOME would prefer what matches your .desktop filename. I don't
> > know what other DEs might prefer.
> 
> Sounds like KDE has considered using a similar scheme:
> 
> """
> * name the application .desktop file using reverse-dns-notation, e.g.
> org.kde.kmail.desktop.  This way we can match the desktop file to the
> dbus service provided by the application, in both directions.
> """
> 
> http://kde-core-devel.kde.narkive.com/ZaOjyDHC/dbus-activated-applications
>  
> > On Tue, Apr 7, 2015 at 7:01 PM, Bryce Harrington <bryce at osg.samsung.com> wrote:
> > > On Tue, Apr 07, 2015 at 05:01:25PM +0800, Jonas Ådahl wrote:
> > >> Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
> > >> ---
> > >>  protocol/xdg-shell.xml | 12 ++++++++++++
> > >>  1 file changed, 12 insertions(+)
> > >>
> > >> diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
> > >> index 3db76ab..c2e1443 100644
> > >> --- a/protocol/xdg-shell.xml
> > >> +++ b/protocol/xdg-shell.xml
> > >> @@ -197,6 +197,18 @@
> > >>       the surface belongs. The compositor can use this to group multiple
> > >>       surfaces together, or to determine how to launch a new application.
> > >>
> > >> +     When applicable, a client should set the app ID to the basename of the
> > >> +     .desktop file associated with the application, for example
> > >> +     "org.freedesktop.FooViewer" where the .desktop file is
> > >> +     "org.freedesktop.FooViewer.desktop".
> > >> +
> > >> +     For D-Bus activatble applications, this will also be D-Bus service
> > >
> > > typo
> > >
> > > Also:  'be *the* D-Bus service'
> > >
> > >> +     name used for activation of the application.
> > >
> > > Does D-Bus depend on having the service name constructed to match the
> > > .desktop file name?  If not, perhaps this paragraph should be moved
> > > ahead of the prior one.  I'm guessing the intention is that we're trying
> > > to say that the D-Bus service name will be the same as the app ID.
> > >
> > > "used for activation of the application" sounds redundant.
> > >
> > >> +     It is not a hard requirement to specify a well formed (as described
> > >> +     above) app ID, but the compositor shell may group the surface
> > >> +     inadequately if the client fail to do so.
> > >
> > > s/fail/fails/
> > >
> > > The way this is written it sounds like a requirement, that's optional,
> > > but has weird side effects if you don't follow it.  So it's a bit
> > > ambiguous whether you really do need to follow it or not.
> > > You might want to elaborate a bit on the implications of not having
> > > things grouped properly, so it's clear what the trade-off is.
> > >
> > > It might help if it was expressed as optional, but with extra features
> > > if you follow it.  Maybe something like:
> > >
> > >     The app ID identifies the general class of applications to which
> > >     the surface belongs. The compositor can use this to group multiple
> > >     applications together, or to determine how to launch a new
> > >     application.
> > >
> > >     For D-Bus activatable applications, the app ID is used as the D-Bus
> > >     service name.
> > >
> > >     The compositor shell will try to group application surfaces together
> > >     by their app ID.  As a best practice, it is suggested to select app
> > >     ID's that match the basename of the application's .desktop file.
> > >     For example, "org.freedesktop.FooViewer" where the .desktop file is
> > >     "org.freedesktop.FooViewer.desktop".
> > >
> > >     See the desktop-entry specification [0] for more details on
> > >     application identifiers and how they relate to well-known DBus
> > >     names and .desktop files.

Whatever you will come up with, I'm sure I'll be fine with it, because
I won't know any better. Feel free to land this patch or any variation
of it, or not.

Not a reason version bump.


Thanks,
pq