On Mon, Jun 18, 2018 at 6:01 PM Simon McVittie <[email protected]> wrote: > > This document might be useful for the D-Bus side: > https://dbus.freedesktop.org/doc/dbus-api-design.html
Hi Simon, thanks for the link. I have read it. Was a good D-Bus overview/introduction I have looked for already for quite some time. Wondering why I never found it before. Should enable me to misuse terminology less often. Thanks for the numerous corrections you did on that in your reply. I won't reply to all of them here, but will integrate them if there is a final proposal. > Do you intend the D-Bus side of the protocol to be equally useful to > X11 apps, or is this a Wayland-only thing? I have only thought about Wayland apps until now, because for X11 / Xwayland in Plasma we have XSMP support. But I'm not against having the mechanism work for X11 apps as well as a replacment for XSMP since GNOME doesn't use it at the moment and thought it was lacking. So yea, if it would work for X11 apps as well, that's fine with me and I will try to help make it happen. > > > and the method being called by the > > compositor on this interface is simply called 'restore' > > D-Bus method names are conventionally in camel-case, so 'Restore'. > > When we discussed this on #gnome-hackers we were talking about doing > restoration by passing the restored session ID as platform_data to the > Activate method defined by > https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus > which would mean that for trivial/stateless apps, it would be enough to > ignore it and just start up, which DBusActivatable implementations like > GtkApplication will already do. Is there a reason why you've opted to define > a new method instead? I think it makes sense to have a separate method, because a client can dbus-activate with the protocol any dbus-activatable app. Imagine a rogue client tries to dbus-activate an app, which is not written to use this extension but provides the Activate method. The compositor tries to dbus-activate it and gets no feedback that this was an operation not doing what it supposed to do. If there is no Restore method, I assume D-Bus would tell it so. The compositor can then show this information to the user. In this sense the protocol should be extended with the information that the Restore method should also return an error, if the restoration id is not found. A rogue client would that way also not be able to silently start a different client, that is supports the protocol (for that to make it secure the restore IDs should be generated through a hash function though). _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
