Window positions under wayland

[samuel ammonius]

I've got an idea: why not just add an API for getting/setting windows
location and let the compositor handle it? It may choose to ignore it,
follow it, follow it on the right monitor, or any number of things. It can
also let the user decide through the preferences. I think it would be a
better solution than both "having" and "not having" this feature.

On Fri, Aug 5, 2022 at 7:12 AM Jean-Michaël Celerier <
jeanmichael.celerier at gmail.com> wrote:

> > This means it *does* have a standard for all windows and the behaviour
> is predictable.
>
> If this had flown in the real world, people would be using UWP apps on
> Windows.
> Enough people disliked that (on the most used desktop OS on the planet)
> that MS had to backtrack and accept Win32's free-for-all API again.
>
> e.g. how do you implement something equivalent to Rainmeter (
> https://www.rainmeter.net/) or AutoHotKey (https://www.autohotkey.com/),
> AutoIt (https://www.autoitscript.com/site/), Macro Creator (
> https://www.macrocreator.com/), etc...
> which could work on every Wayland-based system ? (No one wants to make
> apps that only work on $COMPOSITOR - it's already hard enough to distribute
> Linux apps with the flurry of existing distros, what's even the point in
> spending the effort if
> the portability matrix of a Linux software is now distro * compositor).
> Likewise for things such as
> https://docs.microsoft.com/en-us/windows/powertoys/fancyzones or
> https://github.com/QL-Win/QuickLook/ which have tens of thousands of
> users (QuickLook has almost 1M downloads, it's likely more used than the
> average niche Wayland compositors ; to try to make a Linux equivalent with
> the little data we have, debian's popcon lists sway at 718 reports, versus
> 9800 for xdotool) ?
>
> People here seem to have forgotten that people don't buy computers for
> their compositors, but for the software that allows them to do cool stuff
> with their machines - I don't know a lot of people who care
> about "a standard for all windows" and a unified compositor behaviour
> outside of this mailing-list, but a fair amount who want to be able to do
> autohotkey-ish things for instance (which allows to entirely script and
> control every window, capture all the input, etc).
> Have a look at e.g. the question that people ask on
> https://www.reddit.com/r/AutoHotkey/ to have an idea of what are actual
> human being's needs when using their computers,
> or at why people need SetWindowPos on Win32:
> https://stackoverflow.com/search?tab=newest&q=setwindowpos
>
> It would make me pretty sad to tell these people (both end-users and devs)
> that Windows is a better operating system for their use case than desktop
> Linux.
>
> Cheers,
>
> Jean-Michaël
>
>
>
> ------------------------------
> Jean-Michaël Celerier
> *cto* ossia.io | *consulting inquiries* celtera.dev | *personal*
> jcelerier.name
> t: +336 81 31 53 08
>
>
> On Fri, Aug 5, 2022 at 4:20 AM 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. 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
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20220805/49387c40/attachment-0001.htm>