"Modern" application design stragety question when on Wayland

Desktop
#1

I am aware on Wayland the application is not aware of (nor can manage) it’s window(s) geometries, and with gtk4 accessing this info already got removed and the only way (on X11) is to fall back to native X11 calls.

I am reading in the “Wayland book” to get some more background why and what may be a solution.

“However, a deliberate design trait of Wayland makes application windows ignorant of their exact placement on screen or relative to other windows. This decision affords Wayland compositors a greater deal of flexibility — windows could be shown in several places at once, arranged in the 3D space of a VR scene, or presented in any other novel way. Wayland is designed to be generic and widely applicable to many devices and form factors.” Then mentions some XDG stuff to possibly access this?? I have not clue about at this time.

Well, if you ever 3d (even I do not see that been useful for most application “windows”) – just give me a Z coordinate as well :wink:

So my design problem is a application having more than a single “main window” but also numerous additional window for various tasks, and depending on operation tasks they may be more or less frequently required.
The user normally arranges everything as it fits best his needs. (I am talking about 10 or more plus some varying number of data/image views) – best having them side by side on two or three screens. Generally a big “dash board” for operations.

Now you may imaging once comfortable arranged, it is more than convenient but necessary to store and restore the window layout at next start startup. Now you may say I could use a single huge application window and manage things inside – but why shall I copy that work of a window manager?

Any suggestions?

#2

Well, why do you want to copy this specific task of a window manager then? Saving and restoring window positions is a window manager job too, in the end. (Note that some applications at least save their window size across sessions, and I’d rather have some Wayland interface which delegates that job to the window manager too)

#3

I wish it could do it for me! OSX can fir example.

#4

I really need to know how to store window position and show it with that positions again.

If you find any way please share :slight_smile:

#5

You really don’t. :sweat_smile:

If you’re using X11, you’ll have to use platform-specific API, but it’s going to be a mess because you’ll have to deal with decorations/shadows.

If you’re using Wayland, then you don’t have any way to achieve this; surfaces in Wayland are always at (0, 0), and there is no API to control the position of top levels.

#6

Honestly I am perfectly happy if I do not have to deal with it at all. But allow the user to select the window manager / Wayland to take care of this all for me. I only did it on X11 myself as there also is no service a like. But lucky I could.

I pledge for a Wayland setting to choose for any application to store/restore at next startup the geometry or positions of all windows belonging this app. May it be in the weirdest 3d doom environment :flushed::thinking:

#7

but allow the user to select the window manager / Wayland to take care of this all for me.

That’s currently not possible. Session restore needs cooperation between app/toolkit and compositor.

The app doesn’t know about the global coordinate space, and the compositor doesn’t know that a newly created surface is “the same” as a previous one.

(There’s some work on that, here for example)

#8

I don’t know the details behind the scenes. Don’t need to either.
It’s clearly possible as Wayland must know which windows belong to a application. I at least assume so??

Anyhow I hope this is or may get on feature list and been possible in near future.

Currently on X11 I do store/restore all my apps windows geometry via gsettings I do manage.

#9

“Wayland” doesn’t know anything: it’s a protocol.

A compositor, by definition, knows where each client window is going to be drawn; so, yes: in theory an interface for Wayland compositors could be written to query the position of a surface and restore it.

In practice, it’s a terrible idea, even on X11. Client toolkits have no idea about the workspace layout, or the constraints on a monitor (or set of monitors), or what other clients are doing. Clients should not be responsible for storing window geometry. There are so many caveats that the fact that it “works” on X11 is mostly an accident.

Clients should only ever store their own internal state, because that’s the only thing they can restore successfully; compositors should be responsible for storing, and restoring, the state of the compositor—which includes the running applications. The complicated bit is mapping window state to an application, and it will require help from the application itself.

#10

Ok. Which component level ever – sorry not aware of the particular names and levels here – is putting my windows at seaming random locations currently (testing with Weston) should have the means to recreate next time what I may only once sort out and organize as I like it manually. Vs. every time organizing N windows again and again.
Not sure what kind of app help it may need.
Could be a neat default behavior I bet most people won’t mind or even like having there editor, or tools next time right as they left the session last time.
Also for example take Gimp. I also open the toolbox and layers windows again and move then where i like them to be. Would be nice that been “automagic”!

I sure won’t mind a tool kit interface to tell when to store or restore a widow or all or leaf it to the manager when I open a new not previously opened window. I am talking about unique different task windows and control/monitor windows. Not another “same app” nth new editor window for example.

OSX some what can restore your desktop apps after restart magically…