<div dir="ltr"><div>Hi Jasper,</div><div><br></div><div>Thank you very much for your very clear and comprehensible answer. I understand the challenges you are addressing. </div><div><br></div><div>I want to build applications that can facilitate the screen layout to the fullest and still collaborate with WM.</div><div><br></div><div>I don't really get the "fight" between WM and client. Maybe it is an invitation for someone to build a really nice WM / compositor, satisfying all needs.</div><div><br></div><div>However, stating it bluntly - Client side surface positioning relationship to screen dimensions or multiple screen topology is a must. </div><div><br></div><div>I think it can be done without compromising the simplicity and clarity of the protocol. Or is there something that I am not seeing?</div><div><br></div><div>Thank you,</div><div>Jari Vuomajoki</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 21 November 2017 at 20:02, Jasper St. Pierre <span dir="ltr"><<a href="mailto:jstpierre@mecheye.net" target="_blank">jstpierre@mecheye.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>There's a few reasons that Wayland not to report or allow clients to choose absolute screen position.</div><div><br></div><div>The biggest is that from our experience with X11, it's hard to even *define* such a space. Laptops plug into external monitors and projectors. People with differently sized monitors have gaps -- the space isn't as cleanly defined as a large rectangle. In my experience working on X11 WMs, clients often "fight" the WM over placement, preferring to request a position which is now offscreen because the user undocked their computer. Simply not defining a coordinate space to position windows in is easier than defining one, with all the complexities and edge cases that arrive from 30+ years of developments in computer interaction.</div><div><br></div><div>One of Wayland's design goals is that where possible, compositors, not clients, have the final say. While it can be more difficult to program for, Wayland has concepts based around a relative positioning model. This allows the compositor to place clients where it sees fit, and allows compositors to more freely make constrainment choices so that menus don't get stuck behind taskbar panels, or similar things.</div><div><br></div><div>It certainly has made some things more complicated, so it might have been an overreaction to the complexity we all faced with X11. Hopefully that gives you some insight into why we chose not to expose positioning to the client.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Nov 21, 2017 at 8:47 AM, Jari Vuomajoki <span dir="ltr"><<a href="mailto:rakkaudentuli@gmail.com" target="_blank">rakkaudentuli@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>Hello!</div><div><br></div><div>I have been getting to know the Wayland protocol from the client side for only couple of months... So bare with me if my questions sound immature. </div><div><br></div><div>It took a while to get going, the documentation is there and it is informative enough to build a client. It could be a lot better though or maybe I didn't find a proper source for it. Doxygen documentation ended up being the most useful.</div><div><br></div><div>Here is my list of questions and thoughts. Feel free to anwer or comment on any of them.</div><div><br></div><div>I want to compose clients based on screen dimensions. I know there are fullscreen and maximized options. But I want to have total control of top level surface sizes and placements in the screen. Now talking about single screen, but this can be extented to multiple screens.</div><div><br></div><div>This option is not part of the protocol. I can query the screen size through wl_output interface, so why I cannot position a surface in arbitary position? Why this option has been left out?</div><div><br></div><div>I want to be able to manage the positions of all the top level shell surfaces of the client connection.</div><div><br></div><div>Ok, so now I asked it in three different ways...</div><div><br></div><div>I can naturally extend weston shell and implement this option, but it seems a bit overkill for such a simple option to have. What I am not getting in the picture?</div><div><br></div><div>Best Regards,</div><div>Jari Vuomajoki</div></div>
<br></div></div>______________________________<wbr>_________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedeskto<wbr>p.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_3154541584732206052gmail_signature" data-smartmail="gmail_signature">  Jasper<br></div>
</font></span></div>
</blockquote></div><br></div>