<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 29, 2013 at 7:09 PM, Kristian Høgsberg <span dir="ltr"><<a href="mailto:hoegsberg@gmail.com" target="_blank">hoegsberg@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Nov 29, 2013 at 06:41:59PM -0500, Jasper St. Pierre wrote:<br>
> On Fri, Nov 29, 2013 at 5:43 PM, Kristian Høgsberg <<a href="mailto:hoegsberg@gmail.com">hoegsberg@gmail.com</a>>wrote:<br>
><br>
> > On Wed, Nov 27, 2013 at 03:50:17PM -0200, Rafael Antognolli wrote:<br>
> > > xdg_shell is a protocol aimed to substitute wl_shell in the long term,<br>
> > > but will not be part of the wayland core protocol. It starts as a<br>
> > > non-stable API, aimed to be used as a development place at first, and<br>
> > > once features are defined as required by several desktop shells, we can<br>
> > > finally make it stable.<br>
> > ><br>
> > > It provides mainly two new interfaces: xdg_surface and xdg_popup.<br>
> > ><br>
> > > The xdg_surface interface implements a desktop-style window, that can be<br>
> > > moved, resized, maximized, etc. It provides a request for creating<br>
> > > child/parent relationship, called xdg_surface.set_transient_for.<br>
> > ><br>
> > > The xdg_popup interface implements a desktop-style popup/menu. A<br>
> > > xdg_popup is always transient for another surface, and also has implicit<br>
> > > grab.<br>
> ><br>
> > I think we can land this as is, though there are changes that I'd like<br>
> > to see.  We'll get back to them after we land the series but what I'm<br>
> > thinking is:<br>
> ><br>
> >  - I don't like ping/pong on popup surfaces, and in fact, I think we<br>
> >    can move it to xdg_shell, since it's really a per-client thing, not<br>
> >    a per-surface thing.<br>
> ><br>
> >  - set_transient_for is not a great name.  I know it comes from ICCCM,<br>
> >    but I wonder if we can find a better name.  If it's just stacking,<br>
> >    then maybe just set_aboe?<br>
> ><br>
><br>
> It specifies a parent-child relationship. In mutter, we'll use this to<br>
> attach modal dialogs to their parent windows, for instance.<br>
<br>
</div></div>Saying it's a parent-child relationship doesn't really help - it's a<br>
generic conecept and it's not clear what it might mean in this<br>
context.  Which is why I'd prefer something more specific.  And it<br>
sounds like there's something we're not capturing here: dialogs that<br>
are transient_for will be attached by mutter, but floating toolboxes<br>
are also transient_for but doesn't get attached.  I'm guessing mutter<br>
also looks at wether the window in question is a dialog type or a<br>
toolbox type.<br><div class="im"></div></blockquote><div><br></div><div>I think the rule should be that if your window initiates from another window (e.g. a dialog, or a popup window from a browser), you mark you as part with the originator. I'm fine with adding more detailed semantics later, but I would really have to dig through the mutter codebase to determine all the ways we use transient_for (a cursory look shows that we tie minimization, sticky-state, stacking and workspace switches together).<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> >  - protocol for server-initiated move/resize (eg mod+drag or kb<br>
> >    resize?), probably similar to what we do for server side requestsed<br>
> >    maximize.<br>
> ><br>
><br>
> What protocol is there here?<br>
<br>
</div>When the server initiates a move or resize, the client just sees its<br>
pointer focus disappear and then potentially later come back when the<br>
move/resize is done.  For move, I don't know if we need anything, but<br>
for resize, would could have a "request_resize(edges)" event from the<br>
server that asks the client to trigger a resize.  The client can<br>
ignore if it doesn't feel like resizing or start a resize by sending<br>
the resize request.  This gives the client a more structured way to<br>
decline a resize and wm doesn't try to resize a non-resizable window.<br><div><div class="h5"></div></div></blockquote><div><br></div><div>I've said this before, but I *really* don't this to be a "ignore it if the client wants to" thing. If the user right-clicks on the window and sees a "Resize" menu item, it should always trigger a resize when the user clicks on it. If the window is unresizable, the menu item should be hidden or grayed out.<br>
</div><div><br>Similarly, we implement a Windows 7-like maximization gesture where the user drags the window to the top of the screen to maximize a window. We show a simple blue outline that shows where the window will maximize to on the screen, and if the window is unresizable or its minimum width won't fit in that area, we don't show it.<br>
<br></div><div>If windows want to mark themselves as unresizable, we need to be able to tell that before we give the user the option. I'm fine with a "are you resizable" event to the client, or a declarative state on the surface itself that the compositor keeps, or anything like that (though I'd prefer the declarative WM_HINTS-like approach), but I'm not fine with a "resize if you feel like it today" option, which will end in bad user interfaces.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
> >  - not sure configure needs the edges flag anymore, in the cases where<br>
> >    the server requests a change to the surface size, the server<br>
> >    typically also knows where the window should go.  I think the flag<br>
> >    dates back to before the configure callback and the shell didn't<br>
> >    have a way to intercept the attach.  We relied on the client<br>
> >    passing the right dx/dy, but now the shell gets the configure<br>
> >    callback and can keep the right and top edges in place in case<br>
> >    we're resizing from bottom+left.  This should also fix xwayland<br>
> >    resizing from top or left side.<br>
> ><br>
> >  - we now have set/unset/request_set/request_unset for fullscreen and<br>
> >    maximize, and we'll add minimized, probably tiled_left/right.  This<br>
> >    is going to explode into a large number of requests and events all<br>
> >    with the same structure and flow as the maximized flow we've<br>
> >    discussied this week.  We should consider a more generic approach:<br>
> ><br>
> >     - set(MAXIMIZED), unset(MAXIMIZED) requests, where maximized is an<br>
> >       enum, that is, we don't allow set(MAXIMIZED | FULLSCREEN), but<br>
> >       since it's all atomic under wl_surface.commit,<br>
> >       set(MAXIMIZED)+set(FULLSCREEN) will have the intended effect<br>
> >       (ignore that MAXIMIZED and FULLSCREEN doesn't make sense).<br>
> ><br>
> >     - requet_set(MAXIMIZED) and request_unset(MAXIMIZED) to let the<br>
> >       server intiate the transition.<br>
> ><br>
><br>
> My hesitation with the enum would be people adding their own extensions to<br>
> the enum without standardizing anything...<br>
><br>
> ... if that's something we want (for e.g. tiled-top, tiled-bottom), then we<br>
> should look at maybe having strings as states?<br>
<br>
</div></div>Yeah, strings could work.<br>
<span class="HOEnZb"><font color="#888888"><br>
Kristian<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> Kristian<br>
> ><br>
><br>
> ... snip ...<br>
><br>
><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>
> > 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>
><br>
><br>
> --<br>
>   Jasper<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>  Jasper<br>
</div></div>