On Tue, 7 Apr 2015 19:38:49 -0700 Bryce Harrington <[email protected]> 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 <[email protected]> > > wrote: > > > On Tue, Apr 07, 2015 at 05:01:25PM +0800, Jonas Ådahl wrote: > > >> Signed-off-by: Jonas Ådahl <[email protected]> > > >> --- > > >> 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
