Window positions under wayland

[Thiago Macieira]

On Thursday, 4 August 2022 18:01:34 PDT Igor Korot wrote:
> The very first time the application starts - it will be at position
> (100,100) Then user drags the window to a position (50, 50) and closes the
> application. When he tries to open it next time - (s)he expects the window
> to be placed at position (50, 50).

Rephrasing in Wayland's world: the first time the window opens, it opens at a 
position determined by the compositor. The user drags the window, then closes. 
The next time the window opens, if the compositor was configured to do so, it 
will open where it was last seen.

I don't see anything wrong with this.

> Resolution changes should affect the sizing - not position.

No, they are about position too. 100,100 on a 1920x1080 resolution is about 5% 
to the right of the left edge and 10% from the top. 100,100 on 3840x2160 is 
2.5% from the left and 5% from the top, on the same monitor. The user has a 
right to expect the same finger-width position on the screen, relative to where 
their eyes are looking at.

> Again when you say "clients" - are you talking about software or developers.

He's talking about applications. Terminology from X11 and Wayland: the X11 
server and the Wayland compositor are servers, the applications connect to 
them and are thus clients.

>  However, please remember that HiDPI monitors for laptop is relatively
> new things

They've existed for at least 10 years and have become ubiquitous in the last 5 
or 6. Regardless of whether you've got one or most people have one, we have to 
design the future for them.

> We are now talking about the OS and physically plug or unplug the monitor.
> Plugging in the new monitor shouldn't affect anything on the way the
> application starts.

Yes, it should, if the primary monitor changes. Right now, I am writing to you 
on a 4K monitor @ 3840x2160 resolution, located to the right of the laptop 
screen (also 4K @ 3840x2400). My primary monitor is the one big one, on the 
right, not the one that contains (0,0). That's the one I am looking at, and I 
have positioned it so it's in front of me and my eyes are level with about 1/3 
from the top of the monitor. I expect application windows to show up in front 
of me, not 30° to my left and 15° downward angle, which is where the laptop 
is. Any application that remembers its absolute position has, by simple 
construction, *buggy* UX. And on X11, this happens a lot. The email compositor 
window *always* shows on the left monitor, regardless of where the mouse 
pointer is or I last closed it. One of my browsers shows up on the last 
monitor which I used it, which means about 50% of the time it's wrong too 
because I disconnect the big monitor and take the laptop with me.

As Carsten said, it's far easier to fix the half a dozen compositors that exist 
to understand how the user wants the set up configured than the hundreds of 
applications that each would otherwise control their positions. At best, we 
could fix this in the toolkits (there are basically three of them of relevance 
at this point), but we might still have incompatible behaviour depending on 
which application we the user is using.

> I don't set the explicit parent to the dialog which means it will have a
> Desktop window as a parent.
> And when I call Center(), I do expect the dialog to be centered.

If you did pass a parent, then sure, centering on the parent makes sense and 
the compositor may obey you. It might also think that new windows should 
appear horizontally centre, but vertically at the top (macOS does this).

If you did not pass a parent, then you have no right to expect any position 
relative to the desktop. The Compositor shall choose the best position for the 
new window. It might be centred, or it might be such a way that it won't 
obscure other windows that are already open. Often, it's the screen where the 
pointer mouse is, but there are systems without mice.

The important thing is that the compositor does this for all windows, based on 
the hints supplied by the application. A modal dialog is different from a 
modeless dialog, which is different from a TLW, which is different from a 
floating tool window. This means it *does* have a standard for all windows and 
the behaviour is predictable. Allowing each window to position itself means 
that it is not standard and is not predictable, depending on whether the 
developer of the application in question thought it was a good idea and coded 
it that way -- per window of each application.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering