Best practices for saving and restoring window layout

[Carsten Haitzler (The Rasterman)]

On Fri, 5 Jun 2020 13:09:20 +0300 Pekka Paalanen <ppaalanen at gmail.com> said:

> On Fri, 5 Jun 2020 02:06:00 +1000
> Brad Robinson <brobinson at toptensoftware.com> wrote:
> 
> > Hi All,
> > 
> > First post here...
> > 
> > I'm looking into porting an existing UI library to Gtk+ and I'm struggling
> > to solve a couple of problems related to window positioning when using
> > Wayland as the backend.
> > 
> > I've read through the posts on this list's archive about window positioning
> > and it's clear that a global coordinate system isn't something that Wayland
> > supports - fair enough and I understand the reasons why.
> > 
> > However, I'm wondering what the recommendations are for applications with
> > complicated user-controllable layouts that need to be persisted not only
> > across application runs, but also between documents and across application
> > modes.
> > 
> > For example:
> > 
> > * my application is a music app where the user might have many plugin
> > windows carefully positioned across multiple monitors.
> > * each document file has a different set of plugins loaded and those plugin
> > windows need to be restored to their previous location.
> > * the app can be in "Live" mode or "Edit" mode and switching between modes
> > saves and restores the plugin window locations for each mode.
> > 
> > How should such an app be handled under Wayland?
> > 
> > Note: the app doesn't need to be able to explicitly position windows. It
> > just needs a way to capture and restore a window's position.  An opaque
> > string or data structure that the app can save and use to later reposition
> > a window back to that same place would be perfect.  It would need to be
> > client persistable though - eg: giving a window an id that the window
> > manager can use to store previous geometry probably wouldn't suffice.
> 
> Hi,
> 
> I believe the above is the consensus: ask the server to give you a
> token that records the current state, including position, of the
> window. You store the token, or any number of tokens. When you want to
> recall old state, you pass the token back to the compositor.
> 
> The problem is that I don't remember seeing an extension spec for this.
> It has been talked about, sure, but at least wayland-protocols does not
> seem to have anything for it.

https://git.enlightenment.org/core/enlightenment.git/tree/src/protocol/session-recovery.xml

we have one... already supported in efl too. we use it for recovery across
restarts of the compositor (app doesn't exit when it loses its wl connection -
ti hangs around trying to reconnect every now and again then when it reconnects
it provides this uuid - it could be used for much more).

the xml isn't totally clear... but the compositor creates the uuid and sends it
to the client per surface. clients when recovering set the uuid on a surface so
the compositor can match it up, otherwise they do a get of the uuid. on a clean
shutdown of a window that is not to be recovered they destroy the uuid. you
could destroy it right after successful restoration too.

the compositor then handles restoring state for that uuid (knowing
position/size/virtual desktop and so on).

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com