Window positions under wayland

Fri Aug 5 01:01:34 UTC 2022

Hi, Carsten,

On Thu, Aug 4, 2022 at 6:02 PM Carsten Haitzler <raster at rasterman.com> wrote:
>
> On Thu, 4 Aug 2022 14:46:40 -0500 Igor Korot <ikorot01 at gmail.com> said:
>
> > Hi, Carsten,
> >
> > On Thu, Aug 4, 2022 at 2:31 PM Carsten Haitzler <raster at rasterman.com> wrote:
> > >
> > > On Thu, 4 Aug 2022 13:32:36 -0500 Igor Korot <ikorot01 at gmail.com> said:
> > >
> > > > Hi,
> > > >
> > > > On Thu, Aug 4, 2022 at 12:58 PM samuel ammonius <sfammonius at gmail.com>
> > > > wrote:
> > > > >
> > > > > Dude, I'm trying to persuade the wayland devs to change this, not have
> > > > > an argument about how much wayland sucks. Thanks for explaining that
> > > > > this was supposed to be a feature though. I hadn't known that before.
> > > >
> > > > You most welcome.
> > > > And like I said - you are not the only one. Others tried and failed.
> > > >
> > > > They think its a feature and will tell you "Its by design".
> > >
> > > It is by design. And it's right. From decades of apps being able to
> > > position in X11 and expecting to be able to and then screwing it up again
> > > and again and again... Wayland got it right.
> >
> > I'm not sure what you mean.
> > Can you give an example of "screwing again and again and again...", please?
> >
> > If my code expects the window to be placed at 1 monitor position (100, 100) -
> > what is wrong with that?
> >
> > All I can do as a developer is to write:
> >
> > [pseudo-code]
> > MyApp:MyApp()
> > {
> >      myTLW = new Frame( NULL, ID, "My Beautiful Window", position(
> > 100, 100 ), defaultsize, tlwstyles );
> >      mytklw-> Show( true );
> > }
> > [/pseudo-code]
> >
> > What is wrong with that?
> >
> > Thank you.
>
> let me begin with just a few examples:
>
> 1. window outer frame is decided by wm at runtime. not client (in x11 - you are
> asking about broken examples so they all come from x11). application has no idea
> what frame the wm may choose this time. user may have changed what frame they
> use by default. they may have changed theme which changes frame sizes. they may
> have changed fonts, other sizing factors in wm config which then result in the
> border being put off-screen or in a weird place. clients start to make
> assumptions that wm's will reparent windows in specific ways and add larger
> frames that are immediate children of root when a wm could do anything but they
> all decided to assume this which was a false assumption. they go figuring out
> their inner frame client window vs the immediate child of root to guess frame
> size. this has broken any wm that tries to create a frame that holds multiple
> client windows that are not basically stacked on top of each other. the whole
> idea of icccm and wm policies in theory allow this but invalid client
> assumptions have broken the ability to make experiences better for users.

I don't know what is "Window outer frame".
Are you talking about window decorations, such as borders and title bar?
On top of that - this example talks about sizing. I didn't see anything there
which said "window position". You even explicitly mention sizing there.

Now given my pseudo-code I believe it will be handled nicely in X11 - the window
will be placed at position (100, 100) and will be automatically sized
based on the content.
Not a good example here.

>
> 2. clients are almost all dumb when it comes to dynamic changes. they remember
> their position relative to 0,0 of root generally, but then many forget to
> remember it relative to an xrandr screen and adapt when that xrandr screen
> changes. there is no way to say "put my window at x,y relative to THIS screen"
> only to ask for specific global geometry relative to root, so if screen layout
> changed between invocations - the client gets all their remembered geometry
> wrong. i've seen this countless times and it is the norm for clients - they do
> not adapt to screen layout changes pretty much at all. change resolution,
> rotation, if your monitors are laid out left to right, top to bottom etc. ...
> they just dumbly decide they need to be at 100,213 and want to be there again
> regardless of what changed with screens in the mean time.

When you say "clients" - are you talking about software, TLW or developer?
Now I don't see a problem with that. If I'm an end-user of the software, I want
to open it each time at the same position. It is called "Persistency".
So lets go back to my example.
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).
It doesn't matter what I do with my physical monitor (single), because
it will affect
TLW sizing - not positioning.

>
> 3. specifically just resolution changes - i've never seen a client properly
> decide to re-scale their window position if resolutions changed and/or anchor
> the window to the nearest screen corner to e.g. if window was near bottom-right
> corner now ant now it's 1024x768 and later the screen is 2560x1440 - the window
> stays at bottom-right corner - it will instead now open in the center of the
> screen as the client just remembered its position relative to 0,0 and asks for
> that.

See above.
Resolution changes should affect the sizing - not position.
It should affect how big the graphics is, how big the control is and so the size
of the TLW will be recalculated, but when I say - "position me at (100, 100)"
I expect it to be positioned at (100,100) whatever coordinate system is used
(DPI, DIP or PPP).
>
> 4. the wm has a smart placement policy like centering dialogs on the parent,
> but i have seen clients be dumb enough to just remember position of dialog as an
> absolute (relative to root 0,0) and not relative to their parent window so the
> client parent win was near bottom-right but this time it's near top-left -
> dialog pops up and opens up bottom-right of screen because that is where it was
> centered over the parent window before but now the parent is not there anymore.
> client failed to account for the parent having moved this run.

Again when you say "clients" - are you talking about software or developers.
Now it is a legitimate concern.
 However, please remember that HiDPI monitors for laptop is relatively
new things
and not everybody accounts for this/caught up with this.
As an example - GTK2 will never support HiDPI and GTK3 didn't support it
from 3.2.

>
> 5. some wm's are good at dynamically adapting to new screen layouts and changes
> as you plug and unplug. they may re-index your screens based on a priority
> mechanism and thus your app belongs either on a logical screen (the 2nd highest
> priority of 5 screens) OR it may belong on a physical screen (always that LG 28"
> panel over there - but if not there please fall back to the next screen in my
> priority list). good luck seeing an app do this and then consistently work the
> same way across all apps. wm's can do this and in fact do if you have them
> handle remembering of window geometry and it's a good wm.

Well, its not your priority list, isn't it?
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.
However, if I unplug the monitor I expect my application to move to the next
monitor number the OS assigned it to.

Wouldn't you?
You can change the monitor priority, but that will indicate to the OS how you
will want to handle plug/unplug. Not how you want to position your application's
TLW..And definitely not how you want to size it.

>
> 6. clients are unable to sensibly account for "other tooling" on the screen
> like panels/taskbars/shelves/whatever you want to call them that may move
> around and reconfigure on the fly based on user settings or on current
> state/situation. they are unaware of this in general and it happens when an app
> says "please place my window behind this taskbar" as the taskbar is set by a
> user to be "always on top" thus on top of everything and now moved from left
> edge of screen to bottom but bottom was where a dialog once was 2 seeks ago.
> the app insists on putting a window under the taskbar. if you have to honour
> apps that then assume this you end up with windows that open up invisibly
> behind these "screen tools" and users are confused and don't know where the
> window is. you can't now deny applications to position because then some apps
> like guake (a terminal that pretends to be a quake-like slide-in terminal) 100%
> RELIES on the ability to open a window off-screen and slide it in itself. the
> RIGHT solution is for this window to be of a "type" like let's say "slide in
> window" and either the user can just set this property on ANY window they like
> so you don't need a special apps to do this like guake limit choice and
> perception of what can be done by users. you now can't deny "crazy" positioning
> as it may have some special use case.
>
> 7. what if the wm decides to have a split-screen setup where it divides screens
> into 2? like left and right half and has different virtual desktops on each? how
> can an app sensibly know which "screen" it should be on other than dumbly
> remembering its raw screen geometry not the logical one that only the wm knows?
> if i run the app on the left half this time but next time launch on the
> right half - i want the position chosen to be RELATIVE to the left or right
> half and not absolute - but as above - if you allow absolute positioning you
> can't deny it.
>
> the point of a wm (and wayland compositor) is to not just composite and send
> you input and handle focus changes but to also enforce a POLICY. their job is
> to in whatever way they see if, allow the user to decide what that policy is
> within the capabilities of that wm or compositor. that policy may be a
> mobile-like one where windows always fill the screen - cannot be moved around
> at all and "dialogs" are always e.g. centered on screen or maybe "slide in from
> the side" or whatever the decision is. the policy may be a free-for-all desktop
> style window placement. it may be a hybrid where windows can be placed by a
> user when they choose but the compositor smart-places in spare space or
> whatever. then some windows nicely smart-place as a user expect and some go "no
> - you must put me here" and they disobey the user request/settings to smartly
> place. you end up with every app having its own settings to remember its
> geometry or not and its own logic on how to do this that is invariably broken
> in various ways so users end up with a broken experience.
>
> the point wayland has here is that the mistakes of allowing too much have been
> learned and there is a new expectation base ans it's being enforced. you CAN
> use subsurfaces or render within your window if you want - but they have
> restrictions. rendering in-window means you are limited to the space where your
> window is now. subsurfaces can extend beyond and allow relative positioning but
> you have to handle your own focus display/management for example (or your own
> modality handling etc.).
>
> to be honest - i don't think anyone really wants to go into explaining what
> their decades of experience dealing with all the various broken
> applications/clients is again and again.
>
> the "i want to place wherever i want to and you will place right there" is like
> the programmers of old complaining when MMUs appeared and would then deny them
> access to areas of memory for safety/security. you USED to be able to scan
> through memory and find the memory of some other app and just read it out.
> convenient for finding the data of some other app... but the point of memory
> protection and MMUs is to deny this as it is bad and has lots of side-effects
> and now there is an EXPECTATION that this is denied. likewise denying
> positioning is a similar mental shift that apps have to make - they no longer
> have free reign to just do whatever they please. there are boundaries chosen
> for good reasons.
>
> there might be bigger picture ideas BEHIND that like "i have a password dialog
> for my db app" - then great. make that dialog as such and make sure the
> compositor knows what window it is a dialog for and a good wm/compositor will
> just magically open it centered over the parent window (or over the top center
> or bottom-right corner or whatever the policy that wm has for dialogs is - but
> at least it's now consistent for all apps with dialogs - if that is what the wm
> does - enforce consistency). if the wm/compositor does stupid things with
> dialogs and places them at $RANDOM positions then feel free to yell at the
> compositor for being stupid. there are very many fewer wm and compositors out
> there to yell at than there are applications to yell at, so it's more scalable
> to have the fixes put in compositors not apps. if you absolutely MUST have fine
> control over this .. as i said - you can render in-line in your window, use
> subsurfaces etc. but then you are limited as i described.

If I can make ALL compositors have a policy that the dialog called "Database
Credentials" has to be opened in the middle of the first physical
screen (Screen0) -
I would. Unfortunately it is not possible and even if it is the end uer (a human
being) coud go and change this settings (because application users are dumb).

Also with all this:
How do I expect the following code to behave?

class MyDialog
{
public:
    MyDialog( wxndow *parent,/* rest of the parameters*/);
//rest of the dialog declaration
]

MyDialog dlg( NULL, ..... );
dlg.Center();
dlg.callModal();

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.

However, after all those examples I gathered that I could see this
dialog centered on
Debian, placed at the top of the screen centered horizontally on SlackWare and
centered vertically at the right of the screen on RHEL.

Because remember - you are giving end users (people who will actually
run the software), to tweak the POLICY of the Wayland Compositor. I am
not talking about me as a developer of such an application or a test team
that will have a hell of a time testing it.

Or even worse - what happens when such users will create a compositor setup
for themselves?
You're just going to create havoc. And there will be no standard
behavior for any
*nix application in terms of UI.
Unless of course the end-users of the application wil be working in
the very restrictive
environment where the corporate policy will stop them from
(re-)setting the compositor

Thank you.

>
> > > If you allow positioning then apps RELY on it. They act is totally broken
> > > ways when the compositor refuses to allow that. The right thing to do is to
> > > remove their expectation of such control.
> > >
> > > Apps can use subsurfaces which can position RELATIVE to a parent (e.g. used
> > > for menu popups etc. but could be used for dialogs). You could also just
> > > draw a dialog inline inside your main window and do whatever you want
> > > inside of that. This is up to your app (and whatever toolkit it may use if
> > > it uses one).
> > >
> > > It is the apps' job to indicate a dialog is a dialog for a parent surface.
> > > if they do then the compositor SHOULD place that dialog relative to that
> > > surface sensibly (e.g. centered). If it doesn't do something sensible OR do
> > > what the user has explicitly configured it to do because the user wants
> > > something broken (and the compositor allows it), then that compositor needs
> > > improving/fixing. It's easier to fix a few compositors than it is to fix the
> > > endless chain of 100's of broken applications.
> > >
> > > > Thank you.
> > > >
> > > > >
> > > > > On Thu, Aug 4, 2022 at 3:14 PM Igor Korot <ikorot01 at gmail.com> wrote:
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> On Thu, Aug 4, 2022 at 12:37 PM samuel ammonius <sfammonius at gmail.com>
> > > > >> wrote:
> > > > >> >
> > > > >> > Compositors can prevent apps from doing this if they want to, but
> > > > >> > there needs to be some built-in way for windows to set their
> > > > >> > positions. Not having this isn't a feature.
> > > > >>
> > > > >> I am not a Wayland developer.
> > > > >>
> > > > >> But based on the multiple replies here and there - it is the main
> > > > >> feature of the Wayland.
> > > > >> It will never allow the application to set its position/size.
> > > > >> It will however allow the end-user (a human) to configure Wayland
> > > > >> (compositor) in any waythey want
> > > > >> and however stupid they want.
> > > > >>
> > > > >> And Wayland developers consider it to be "BIG WAYLAND FEATURE".
> > > > >>
> > > > >> So forget about cross-platform applications behaving the same, forget
> > > > >> about even writing sane application on Linux.
> > > > >> Wayland (compositor) will be set up by the user (a human) in such a
> > > > >> way so that the application could become
> > > > >> completely unusable.
> > > > >>
> > > > >> Thank you.
> > > > >>
> > > > >> >
> > > > >> > On Thu, Aug 4, 2022 at 2:57 PM Igor Korot <ikorot01 at gmail.com> wrote:
> > > > >> >>
> > > > >> >> On Thu, Aug 4, 2022 at 12:06 PM Simon Ser <contact at emersion.fr>
> > > > >> >> wrote:
> > > > >> >> >
> > > > >> >> > On Thursday, August 4th, 2022 at 19:00, samuel ammonius
> > > > >> >> > <sfammonius at gmail.com> wrote:
> > > > >> >> >
> > > > >> >> > > apps such as popups and dialogs are usually supposed to start
> > > > >> >> > > either at the center of the screen or the center of their
> > > > >> >> > > parent app
> > > > >> >>
> > > > >> >> You are barking at the wrong tree.
> > > > >> >>
> > > > >> >> Apparently this is the main feature of the Wayland - do not let the
> > > > >> >> developers set up the position of the TLW.
> > > > >> >>
> > > > >> >> >
> > > > >> >> > That's usually what compositors do: center apps by default. But
> > > > >> >> > it's to the compositor and user preference.
> > > > >> >> >
> > > > >> >> > > apps often want to remember where they were when they closed so
> > > > >> >> > > they can open there again
> > > > >> >> >
> > > > >> >> > This is what [1] addresses.
> > > > >> >> >
> > > > >> >> > [1]:
> > > > >> >> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
> > > > >> >>
> > > > >> >> Finally!! ;-)
> > > > >> >> Now if only Wayland can respect the calls such as
> > > > >> >> CenterOnScreen()/CenterOnParent()
> > > > >> >> for the dialog-like windows it would be great.
> > > > >> >>
> > > > >> >> Unfortunately it looks like this will never happen and the
> > > > >> >> application developers will
> > > > >> >> have to throw away their software, because apparently dialogs can be
> > > > >> >> put anywhere
> > > > >> >> on the screen.
> > > > >> >>
> > > > >> >> Something like a dialog asking for credentials to login to the DB
> > > > >> >> that shows up in the
> > > > >> >> top left corner, because some idiot user set it this way.
> > > > >> >>
> > > > >> >> Thank you.
> > > >
> > >
> > >
> > > --
> > > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > > Carsten Haitzler - raster at rasterman.com
> > >
> >
>
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> Carsten Haitzler - raster at rasterman.com
>