Window positions under wayland

[Igor Korot]

Hi, Thiago,

On Thu, Aug 4, 2022 at 9:20 PM Thiago Macieira <thiago at kde.org> wrote:
>
> 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.

Why?
Every system in *nix world is different and therefore uses different
WM/compositor
If the window position is defined by the WM/compositor, it means I, as
a developer,
can't write portable code.

> 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.

Wrong.
The window position is defined by the compositor.
So if my window position is (50, 50 ) before closing, but the
compositor dictates the window
to be placed in the center of the screen - it will be placed in the
center of the screen.

No matter what I, or the user of my application, will do.

And yes - I do see a problem with that (see above - no portable code).

>
> > 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.

No, they are not.
It should be up to the application to decide the coordinate system PPI/DPI/etc.
A human being shuold expect the application to be open dependent on the
documented way the application is opening.
If the documentation says - "expect the window to open at (100, 100) in DPI
coordinates" - this is where I will look. Everything else will be
considered a bug of the UI.
But with Wayland - opening a window at (100, 100 ) is not possible because
a compositor in a vast majority of cases will override that.
And the window might be opening at position ( 1000, 1000 ) for FWIW.
Will you expect that? I certainly won't.

>
> > 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.

Correct.

>
> > 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.

Plugging in a new monitor shouldn't affect the primary monitor, as
"primary != new".
After doing so the user can go and choose his primary monitor, but
that is completely
different from plugging in the monitor.

I hope you see my point.(9)%
> 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.

Absolutely agree with the above sentence.
Applications should define what coordinate system they will use and store the
coordinates appropriately.
Moreover - they shouldn't save their size as it will be determined by
the content
of the window. I hope you agree with my last sentence.

> And on X11, this happens a lot. The email compositor
> window

I'm sorry - what is "an E-mail compositor window"?
Are you saying that every application in Wayland will have its own compositor?
Or am I missing something?

> *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.

I don't know about that.
At work I have a laptop with the monitor and 2 external ones.
We use RHEL8 and we set it up to use X11 classic configuration.
We also use basic GNOME as WM.

Both of my monitors and the laptop are connected to the docking station,.

My main monitor (by main I mean the one where the GNOME menu
is displayed) is one of the externals (one on the left). Then the middle one
is the laptop one and the right one where I keep the Eclipse.

When I disconnect the laptop and go home (no shutdown!!) and then connect
the laptop and then open it - everything is displayed on the laptop monitor.
Nothing is off screen.
Switching to Eclipse I can see it on the laptop.

Going back to work is a different beast - I'm not shutting down my laptop and so
everything that was open on the monitor is still displaying on the
laptop monitor
and not on the external one.

>
> 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 behavior depending on
> which application we the user is using.

If we clearly define that every single application shuold use
DPI/PPI/whatever for their
positioning - we can fix the 3 toolkits (BTW why 3, I only know 2 - GTK and Qt).
Then applications may not need to do anything.
Or they will have to do a minimal changes.

>
> > 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).

The key word here is "may obey you".
One more time - when one system centers the dialog, the other pushes it
to the top-right corner where the power button is (in GNOME), and a thrid
pushes it to the lower left corner (where menu button is in K) - the
behavior is
buggy.

>
> If you did not pass a parent, then you have no right to expect any position
> relative to the desktop.

Yes, I do.
When I don't set the parent window to the dialog, I expect the parent
window to be a Desktop. Thais what 99.(9)% of the applications and their
developers expects.
And so the dialog should be positioned exactly as asked - in the
center of the Desktop.
(if the application do call Center(), of course).
If it doesn't - well, then yes, the compositor might kick in and
define the position
for such dialog. But this case is (in my experience) rare.

>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.

You are wrong again.
Ther compositor choosing the window position based either on some arbitrary
algorythm or the end-user (a human) configuration/setup.

> A modal dialog is different from a
> modeless dialog, which is different from a TLW, which is different from a
> floating tool window.

As a developer I consider modal dialogs to be TLW and a "tool windo"/modeless
dialog is not.

That's why (at least in my code), I use NULL as a parent for dialogs,
because I never needed modeless dialog (yet to find a scenario
where one is abolutely shuold be used ve {mini} frame).

> 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.

Its funny how people in software development world use the word "predictable"
The prodictable network interface name would "eth0", ", "wlan0",
"eth1", "wlan1".
Instead the current way of calling the interface predictable is
"wpad3v6" or something
to that extent.
How can a normal human being predict that? ;-)

Thank you.

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