On Thu, 4 Aug 2022 14:46:40 -0500 Igor Korot <ikoro...@gmail.com> said:
> Hi, Carsten, > > On Thu, Aug 4, 2022 at 2:31 PM Carsten Haitzler <ras...@rasterman.com> wrote: > > > > On Thu, 4 Aug 2022 13:32:36 -0500 Igor Korot <ikoro...@gmail.com> said: > > > > > Hi, > > > > > > On Thu, Aug 4, 2022 at 12:58 PM samuel ammonius <sfammon...@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 <ikoro...@gmail.com> wrote: > > > >> > > > >> Hi, > > > >> > > > >> On Thu, Aug 4, 2022 at 12:37 PM samuel ammonius <sfammon...@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 <ikoro...@gmail.com> wrote: > > > >> >> > > > >> >> On Thu, Aug 4, 2022 at 12:06 PM Simon Ser <cont...@emersion.fr> > > > >> >> 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. > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > Carsten Haitzler - ras...@rasterman.com > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com