Window positions under wayland

Thu Aug 4 23:01:23 UTC 2022

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.

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.

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.

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.

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.

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