Best practices for saving and restoring window layout

Scott Anderson scott.anderson at collabora.com
Fri Jun 5 10:34:25 UTC 2020


On 5/06/20 10:09 pm, Pekka Paalanen wrote:
> 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.
> 
> 
> Thanks,
> pq
> 

A protocol was that was proposed relatively recently.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18

>> I'm about to refactor a big part of the code that handles this and now is
>> the time I can make conceptual changes that could better cater for Wayland
>> as a back end. I've seen comments in the archive about how a global
>> coordinate system isn't necessary and that issues related to a lack of one
>> can be better solved by other means but I'm not sure what those other means
>> are and I'm struggling to see a way forward with this.
>>
>> Any thoughts, suggestions, recommendations greatly appreciated.
>>
>> Brad
> 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 



More information about the wayland-devel mailing list