Window positions under wayland
I hope this hasn't been said a million times before, because I don't mean to pressure anyone. I'm not a wayland contributor. I just wanted to say that Wayland should really consider letting windows get/set their positions. The main reasons are that 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, and that apps often want to remember where they were when they closed so they can open there again. Could something like this ever be added?
Re: Window positions under wayland
On Thursday, August 4th, 2022 at 19:00, samuel ammonius 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 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
Re: Window positions under wayland
On Thu, Aug 4, 2022 at 12:06 PM Simon Ser wrote: > > On Thursday, August 4th, 2022 at 19:00, samuel ammonius > 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.
Re: Window positions under wayland
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. On Thu, Aug 4, 2022 at 2:57 PM Igor Korot wrote: > On Thu, Aug 4, 2022 at 12:06 PM Simon Ser wrote: > > > > On Thursday, August 4th, 2022 at 19:00, samuel ammonius < > sfammon...@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. >
Re: Window positions under wayland
Hi, On Thu, Aug 4, 2022 at 12:37 PM samuel ammonius 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 wrote: >> >> On Thu, Aug 4, 2022 at 12:06 PM Simon Ser wrote: >> > >> > On Thursday, August 4th, 2022 at 19:00, samuel ammonius >> > 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.
Re: Window positions under wayland
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. On Thu, Aug 4, 2022 at 3:14 PM Igor Korot wrote: > Hi, > > On Thu, Aug 4, 2022 at 12:37 PM samuel ammonius > 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 wrote: > >> > >> On Thu, Aug 4, 2022 at 12:06 PM Simon Ser wrote: > >> > > >> > On Thursday, August 4th, 2022 at 19:00, samuel ammonius < > sfammon...@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. >
Re: Window positions under wayland
Hi, On Thu, Aug 4, 2022 at 12:58 PM samuel ammonius 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". Thank you. > > On Thu, Aug 4, 2022 at 3:14 PM Igor Korot wrote: >> >> Hi, >> >> On Thu, Aug 4, 2022 at 12:37 PM samuel ammonius 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 wrote: >> >> >> >> On Thu, Aug 4, 2022 at 12:06 PM Simon Ser wrote: >> >> > >> >> > On Thursday, August 4th, 2022 at 19:00, samuel ammonius >> >> > 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.
Re: Window positions under wayland
On Thu, 4 Aug 2022 13:32:36 -0500 Igor Korot said: > Hi, > > On Thu, Aug 4, 2022 at 12:58 PM samuel ammonius 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. 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 wrote: > >> > >> Hi, > >> > >> On Thu, Aug 4, 2022 at 12:37 PM samuel ammonius > >> 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 wrote: > >> >> > >> >> On Thu, Aug 4, 2022 at 12:06 PM Simon Ser wrote: > >> >> > > >> >> > On Thursday, August 4th, 2022 at 19:00, samuel ammonius > >> >> > 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 - ras...@rasterman.com
Re: Window positions under wayland
Hi, Carsten,
On Thu, Aug 4, 2022 at 2:31 PM Carsten Haitzler wrote:
>
> On Thu, 4 Aug 2022 13:32:36 -0500 Igor Korot said:
>
> > Hi,
> >
> > On Thu, Aug 4, 2022 at 12:58 PM samuel ammonius
> > 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.
>
> 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 wrote:
> > >>
> > >> Hi,
> > >>
> > >> On Thu, Aug 4, 2022 at 12:37 PM samuel ammonius
> > >> 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 wrote:
> > >> >>
> > >> >> On Thu, Aug 4, 2022 at 12:06 PM Simon Ser wrote:
> > >> >> >
> > >> >> > On Thursday, August 4th, 2022 at 19:00, samuel ammonius
> > >> >> > 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.
> > >>
Re: Window positions under wayland
On Thu, 4 Aug 2022 14:46:40 -0500 Igor Korot said:
> Hi, Carsten,
>
> On Thu, Aug 4, 2022 at 2:31 PM Carsten Haitzler wrote:
> >
> > On Thu, 4 Aug 2022 13:32:36 -0500 Igor Korot said:
> >
> > > Hi,
> > >
> > > On Thu, Aug 4, 2022 at 12:58 PM samuel ammonius
> > > 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
Re: Window positions under wayland
On Thursday, 4 August 2022 16:01:23 PDT Carsten Haitzler wrote: > 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. Indeed, this is mostly an X/Y problem. You have an X problem (unrelated to X11, just using the letter of the alphabet) and you think you need Y to achieve it, as in the example above: in order to properly place some dialog, the application needed to get the absolute position of the window it's going to be relative to and then position the new window at a specific absolute position. So we get people coming and asking about how to do Y (this implementation). Instead, we need to know what the X problem was: properly positioning the sub- window or sibling window, or application window reappearing close to where you've last seen it. There are probably better ways of solving that problem than the reintroducing all the legacy that Carsten is talking about. This is why Wayland developers keep saying that absolute positions being unavailable is a feature, not a bug. There may come a time when the number of protocol extensions to support all the little things that one could do with absolute positioning becomes a burden, but we're not there and have yet to see a problem that can't be solved differently. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: Window positions under wayland
Hi, Carsten,
On Thu, Aug 4, 2022 at 6:02 PM Carsten Haitzler wrote:
>
> On Thu, 4 Aug 2022 14:46:40 -0500 Igor Korot said:
>
> > Hi, Carsten,
> >
> > On Thu, Aug 4, 2022 at 2:31 PM Carsten Haitzler
> > wrote:
> > >
> > > On Thu, 4 Aug 2022 13:32:36 -0500 Igor Korot said:
> > >
> > > > Hi,
> > > >
> > > > On Thu, Aug 4, 2022 at 12:58 PM samuel ammonius
> > > > 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 2560
Re: Window positions under wayland
Hi, Thiago, On Thu, Aug 4, 2022 at 8:09 PM Thiago Macieira wrote: > > On Thursday, 4 August 2022 16:01:23 PDT Carsten Haitzler wrote: > > 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. > > Indeed, this is mostly an X/Y problem. > > You have an X problem (unrelated to X11, just using the letter of the > alphabet) and you think you need Y to achieve it, as in the example above: in > order to properly place some dialog, the application needed to get the > absolute position of the window it's going to be relative to and then position > the new window at a specific absolute position. So we get people coming and > asking about how to do Y (this implementation). > > Instead, we need to know what the X problem was: properly positioning the sub- > window or sibling window, or application window reappearing close to where > you've last seen it. There are probably better ways of solving that problem > than the reintroducing all the legacy that Carsten is talking about. Please check my reply to Carsten. You will see 2 code snippets and the explanation of some stuff I'm looking for as well as a critique of Carsten's sample. I do think some samples are legitimate, but doing what Wayland is doing is not a solution for them. Thank you. > > This is why Wayland developers keep saying that absolute positions being > unavailable is a feature, not a bug. There may come a time when the number of > protocol extensions to support all the little things that one could do with > absolute positioning becomes a burden, but we're not there and have yet to see > a problem that can't be solved differently. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >Software Architect - Intel DCAI Cloud Engineering > > >
Re: Window positions under wayland
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
