<br><br><div class="gmail_quote">2010/11/29 Fred Morcos <span dir="ltr"><<a href="mailto:fred.morcos@gmail.com">fred.morcos@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2010/11/29 Kristian Høgsberg <<a href="mailto:krh@bitplanet.net">krh@bitplanet.net</a>>:<br>
<div><div></div><div class="h5">> On Thu, Nov 25, 2010 at 9:43 PM, Gerry JJ <<a href="mailto:trick@icculus.org">trick@icculus.org</a>> wrote:<br>
>> Den Wed, 24 Nov 2010 13:01:06 -0500<br>
>> skrev Marty Jack <<a href="mailto:martyj19@comcast.net">martyj19@comcast.net</a>>:<br>
>>> Also, I don't yet fully buy<br>
>>> into the part about no client controlled window placement. We need<br>
>>> some way for docks to position themselves appropriately.<br>
>><br>
>> Client controlled window placement is important. Without it, you<br>
>> can't restore multi-window sessions properly (or even single-window, if<br>
>> position matters), splash screens won't be centered as they should be,<br>
>> dialog boxes will pop up at random positions, and whatever else that<br>
>> wants to put specific windows at specific positions on the screen for<br>
>> other (possibly good) reasons won't work. Some things may have less<br>
>> valid reasons, but that's a tiny issue compared to not being able to do<br>
>> all those things properly under Wayland.<br>
><br>
> All of those can be handled by the compositor. The key is to let the<br>
> compositor know what kind of window you're showing and how it relates<br>
> to your other windows. Once the compositor knows whether you're<br>
> showing a new toplevel window, a dialog box for an existing window or<br>
> a popup menu, the compositor/wm is always in a better position than<br>
> the client to determine where that window should be. The core of the<br>
> issue is that the compositor may at any time be applying<br>
> transformations to the clients windows that it can't express to the<br>
> client. If a client computes the exact location of a dialog box or<br>
> popup menu, there is an implicit assumption that the client knows it<br>
> current location and can compute from that a good location for the new<br>
> window. That's just not the case in a composited environment and it's<br>
> one of the assumption that makes it impossible to really fix input<br>
> redirection.<br>
><br>
> (Disclaimer: session management isn't even at the hand-waving stage<br>
> yet, but I'm pretty sure we can deal with that without requiring<br>
> clients to specific their position on screen).<br>
><br>
> Kristian<br>
> _______________________________________________<br>
> wayland-devel mailing list<br>
> <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
><br>
<br>
</div></div>I second Kristian's opinion. Panels can request certain placements in<br>
sequence of their priorities (left, right, top-left, ...) and the<br>
compositor will be the best to decide which area is free<br>
(non-overlapping with any other panels already running) to contain<br>
that panel. I find that quite nice but also limiting.<br></blockquote><div><br></div><div>One big problem in the current iteration of the wm-spec under X is that multiple panels sharing the edge conflict and there is no nice way atm to specify their positions properly. The WM is in control of behaviour, but then various WMs give various amounts of control to applications, which then come to depend on it to work properly. Which in the end means that apps only work correctly under some WMs. I think personally that all control of behaviour should be in the WM. It is only as limiting as the protocol/interface which really is unbounded.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I wonder, isn't that problem analogous to the client-side decorations?<br>
Allowing client-side decorations but rejecting client-side placement<br>
seems hypocritical to me.<br></blockquote><div><br></div><div>They are completely orthogonal issues, so I don't agree. One is visible drawing of the window, and one is behaviour.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I really think the X way (server, wm and clients) is the best way and<br>
truly is one-size-fits-all. A humble idea that I thought of was to<br>
have:<br>
wayland <-> [compositor <-> decorator] <-> clients (where <-> denotes<br>
talks-to)... But that looks awfully familiar...<br></blockquote><div><br></div><div>Well, wayland is the compositor, so there is no use separating them out here. This is just describing the X server environment, which you stated you like, but a wayland compositor is a different kind of environment.</div>
<div><br></div><div><br></div><div>- Dana</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Regards,<br>
<font color="#888888">Fred Morcos<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br>