<div dir="ltr"><div>> This means it *does* have a standard for all windows and the behaviour is predictable.</div><div><br></div><div>If this had flown in the real world, people would be using UWP apps on Windows. <br></div><div>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.</div><div><br></div><div>e.g. how do you implement something equivalent to Rainmeter (<a href="https://www.rainmeter.net/">https://www.rainmeter.net/</a>) or AutoHotKey (<a href="https://www.autohotkey.com/">https://www.autohotkey.com/</a>), AutoIt (<a href="https://www.autoitscript.com/site/">https://www.autoitscript.com/site/</a>), Macro Creator (<a href="https://www.macrocreator.com/">https://www.macrocreator.com/</a>), etc...</div><div>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 <br></div><div>the portability matrix of a Linux software is now distro * compositor).</div><div>Likewise for things such as <a href="https://docs.microsoft.com/en-us/windows/powertoys/fancyzones">https://docs.microsoft.com/en-us/windows/powertoys/fancyzones</a> or <a href="https://github.com/QL-Win/QuickLook/">https://github.com/QL-Win/QuickLook/</a> 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) ? <br></div><div><br></div><div>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 <br></div><div>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 <br></div><div>control every window, capture all the input, etc). <br></div><div>Have a look at e.g. the question that people ask on <a href="https://www.reddit.com/r/AutoHotkey/">https://www.reddit.com/r/AutoHotkey/</a> to have an idea of what are actual human being's needs when using their computers, <br></div><div>or at why people need SetWindowPos on Win32: <a href="https://stackoverflow.com/search?tab=newest&q=setwindowpos">https://stackoverflow.com/search?tab=newest&q=setwindowpos</a> <br></div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div><br></div><div>Jean-Michaël<br></div><div><br></div><div><br> </div><div><br><span class="gmail-im"></span></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><hr><div><div><div>Jean-Michaël Celerier</div><div><b>cto</b> <a href="http://ossia.io" target="_blank">ossia.io</a> | <b>consulting inquiries</b> <a href="http://celtera.dev" target="_blank">celtera.dev</a> | <b>personal</b> <a href="http://jcelerier.name" target="_blank">jcelerier.name</a></div><div>t: +336 81 31 53 08<br></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 5, 2022 at 4:20 AM Thiago Macieira <<a href="mailto:thiago@kde.org">thiago@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thursday, 4 August 2022 18:01:34 PDT Igor Korot wrote:<br>
> The very first time the application starts - it will be at position<br>
> (100,100) Then user drags the window to a position (50, 50) and closes the<br>
> application. When he tries to open it next time - (s)he expects the window<br>
> to be placed at position (50, 50).<br>
<br>
Rephrasing in Wayland's world: the first time the window opens, it opens at a <br>
position determined by the compositor. The user drags the window, then closes. <br>
The next time the window opens, if the compositor was configured to do so, it <br>
will open where it was last seen.<br>
<br>
I don't see anything wrong with this.<br>
<br>
> Resolution changes should affect the sizing - not position.<br>
<br>
No, they are about position too. 100,100 on a 1920x1080 resolution is about 5% <br>
to the right of the left edge and 10% from the top. 100,100 on 3840x2160 is <br>
2.5% from the left and 5% from the top, on the same monitor. The user has a <br>
right to expect the same finger-width position on the screen, relative to where <br>
their eyes are looking at.<br>
<br>
> Again when you say "clients" - are you talking about software or developers.<br>
<br>
He's talking about applications. Terminology from X11 and Wayland: the X11 <br>
server and the Wayland compositor are servers, the applications connect to <br>
them and are thus clients.<br>
<br>
>  However, please remember that HiDPI monitors for laptop is relatively<br>
> new things<br>
<br>
They've existed for at least 10 years and have become ubiquitous in the last 5 <br>
or 6. Regardless of whether you've got one or most people have one, we have to <br>
design the future for them.<br>
<br>
> We are now talking about the OS and physically plug or unplug the monitor.<br>
> Plugging in the new monitor shouldn't affect anything on the way the<br>
> application starts.<br>
<br>
Yes, it should, if the primary monitor changes. Right now, I am writing to you <br>
on a 4K monitor @ 3840x2160 resolution, located to the right of the laptop <br>
screen (also 4K @ 3840x2400). My primary monitor is the one big one, on the <br>
right, not the one that contains (0,0). That's the one I am looking at, and I <br>
have positioned it so it's in front of me and my eyes are level with about 1/3 <br>
from the top of the monitor. I expect application windows to show up in front <br>
of me, not 30° to my left and 15° downward angle, which is where the laptop <br>
is. Any application that remembers its absolute position has, by simple <br>
construction, *buggy* UX. And on X11, this happens a lot. The email compositor <br>
window *always* shows on the left monitor, regardless of where the mouse <br>
pointer is or I last closed it. One of my browsers shows up on the last <br>
monitor which I used it, which means about 50% of the time it's wrong too <br>
because I disconnect the big monitor and take the laptop with me.<br>
<br>
As Carsten said, it's far easier to fix the half a dozen compositors that exist <br>
to understand how the user wants the set up configured than the hundreds of <br>
applications that each would otherwise control their positions. At best, we <br>
could fix this in the toolkits (there are basically three of them of relevance <br>
at this point), but we might still have incompatible behaviour depending on <br>
which application we the user is using.<br>
<br>
> I don't set the explicit parent to the dialog which means it will have a<br>
> Desktop window as a parent.<br>
> And when I call Center(), I do expect the dialog to be centered.<br>
<br>
If you did pass a parent, then sure, centering on the parent makes sense and <br>
the compositor may obey you. It might also think that new windows should <br>
appear horizontally centre, but vertically at the top (macOS does this).<br>
<br>
If you did not pass a parent, then you have no right to expect any position <br>
relative to the desktop. The Compositor shall choose the best position for the <br>
new window. It might be centred, or it might be such a way that it won't <br>
obscure other windows that are already open. Often, it's the screen where the <br>
pointer mouse is, but there are systems without mice.<br>
<br>
The important thing is that the compositor does this for all windows, based on <br>
the hints supplied by the application. A modal dialog is different from a <br>
modeless dialog, which is different from a TLW, which is different from a <br>
floating tool window. This means it *does* have a standard for all windows and <br>
the behaviour is predictable. Allowing each window to position itself means <br>
that it is not standard and is not predictable, depending on whether the <br>
developer of the application in question thought it was a good idea and coded <br>
it that way -- per window of each application.<br>
<br>
-- <br>
Thiago Macieira - thiago (AT) <a href="http://macieira.info" rel="noreferrer" target="_blank">macieira.info</a> - thiago (AT) <a href="http://kde.org" rel="noreferrer" target="_blank">kde.org</a><br>
   Software Architect - Intel DCAI Cloud Engineering<br>
<br>
<br>
<br>
</blockquote></div>