<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi All,<div><br></div><div>First post here...</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div></div><div><br></div><div>For example:</div><div><br></div><div>* my application is a music app where the user might have many plugin windows carefully positioned across multiple monitors.</div><div>* each document file has a different set of plugins loaded and those plugin windows need to be restored to their previous location.</div><div>* the app can be in "Live" mode or "Edit" mode and switching between modes saves and restores the plugin window locations for each mode.</div><div><br></div><div>How should such an app be handled under Wayland?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Any thoughts, suggestions, recommendations greatly appreciated.</div><div><br></div><div>Brad</div><div><br></div><div><br></div></div></div></div>