As a general remark I want to expand upon, why I did work on this protocol although Mike's xdg-session-management protocol already existed:
The xdg-session-management protocol defines only how certain sessions / surfaces can be saved for later restoration and how to restore them. But it does not define conditions on if saving is suitable at the moment and how long the compositor needs to remember the saved restoration info. I believe in particular the last point is crucial, and the client needs to negotiate this with the compositor somehow depending on what it wants to do with the restoration info. My proposal tries to solve this by defining very tight concepts (sleep, quit, shutdown) on what the saved surface info is intended to be used for and allows the compositor to remove surface data, that has not been recovered in the boundaries of these concepts. And having DBus-Activation (or the Exec line of desktop files) defined in the protocol as the way to restore an app after it has quit the Wayland connection has the advantages that all information are in one place and that client developers have it easier, since they can rest assure that if they target this one spec and the compositor supports the suspension level, the workspace will at some point reactivate their app in a predictable manner. _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
