<div dir="ltr">No one responded to my last email, so I'll just assume it was because everyone aggeed with it and not because it was so horribly structured that no one understood a thing I was saying :).<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It would be possible to redesign Wayland following the principles you<br>have described. No-one is doing this, however.<br></blockquote><div>If I added this feature through git, would it be accepted? It would just be "void wl_surface_request_position(wl_surface *surface, unsigned int x, unsigned int y);" </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 5, 2022 at 8:14 PM samuel ammonius <<a href="mailto:sfammonius@gmail.com">sfammonius@gmail.com</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"><div dir="ltr">Sorry, I just read over my last email and realized that I didn't even state what I was trying<div>to say. I meant my last suggestion of letting the compositor handle the resize event. I was</div><div>just giving some reasons as to why it may be the best solution.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 5, 2022 at 6:32 PM samuel ammonius <<a href="mailto:sfammonius@gmail.com" target="_blank">sfammonius@gmail.com</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"><div dir="ltr"><div dir="ltr"><div id="gmail-m_-6489129043984878910gmail-m_4035675142571669710gmail-:ok" aria-label="Message Body" role="textbox" aria-multiline="true" style="direction:ltr;min-height:85px" aria-controls=":rv"><div>I don't understand why we're all asking if it should be up to the compositor or app to set a</div><div>window's position. The only correct answer is that it should be up to the user, so I don't</div><div>see what's wrong with my suggestion of a "set window size request" function. Waylands</div><div>idea of not letting apps set their window position because it thinks it knows better is very</div><div>similar to what's wrong with commercial operating systems nowadays, and it's probably</div><div>why many of us left Windows. For example, you could only disable "live security" in the</div><div>settings for up to 10 minutes to speed up a download, and you aren't given an option to</div><div>never update the operating system (if you wanted to increase the life expectancy of your</div><div>SSD, for example).</div><div><br></div><div>The only compromise in this case that truly gives users full control is one where users</div><div>get to configure their compositor to either.</div><div>1) Allow apps to freely set their positions</div><div>2) Have the window manager make them start in the center or at their last location</div><div>3) Use the position apps request to make smart decisions about how the app should</div><div>     be placed (for example, if an app always starts at (100, 100) on a 1000x700 monitor,</div><div>     but the user has recently switched to a new 3000x2400 monitor, then the app can be</div><div>     placed at (300, 300))</div><div>The user can also configure individual apps to start in different ways if they chose to</div><div>allow apps to pick their positions, or some compositors can even give users the option to</div><div>apply the above to certain apps separately.</div><div><br></div><div>This design gives everyone 200% of what they asked for. Compositors can obtain even</div><div>more information about how a window should be placed, and windows can choose their</div><div>own locations knowing that the compositor will optimize that position for the users screen</div><div>to make sure they don't make any mistakes. I don't see a single thing that this takes away</div><div>from Waylands current design.</div><div><br></div><div>Also, as Igor said, flags on how the compositor should interpret the size request would be</div><div>a great feature as well. There could be flags for priority, relative/absolute positioning, or</div><div>any number of other things that could be added in the future. (Qt uses a genius flag system,</div><div>where each flag is double the last one so they can just be added to each other and no two</div><div>combinations of them will match. For example: NO_FLAGS = 0x00, FLAG_A = 0x01,</div><div>FLAG_B = 0x02, FLAG_C = 0x04, FLAG_D = 0x08, FLAG_E = 0x10, FLAG_F = 0x20, etc...,</div><div>and then the flags could be used like "FLAG_B | FLAG_E" ("|" is an uncommon C/C++</div><div>feature for adding constants without optimization). It's probably irrelevant but it's really cool)</div></div></div></div>
</blockquote></div>
</blockquote></div>