On Fri, Nov 29, 2013 at 5:43 PM, Kristian Høgsberg <hoegsb...@gmail.com>wrote:
> On Wed, Nov 27, 2013 at 03:50:17PM -0200, Rafael Antognolli wrote: > > xdg_shell is a protocol aimed to substitute wl_shell in the long term, > > but will not be part of the wayland core protocol. It starts as a > > non-stable API, aimed to be used as a development place at first, and > > once features are defined as required by several desktop shells, we can > > finally make it stable. > > > > It provides mainly two new interfaces: xdg_surface and xdg_popup. > > > > The xdg_surface interface implements a desktop-style window, that can be > > moved, resized, maximized, etc. It provides a request for creating > > child/parent relationship, called xdg_surface.set_transient_for. > > > > The xdg_popup interface implements a desktop-style popup/menu. A > > xdg_popup is always transient for another surface, and also has implicit > > grab. > > I think we can land this as is, though there are changes that I'd like > to see. We'll get back to them after we land the series but what I'm > thinking is: > > - I don't like ping/pong on popup surfaces, and in fact, I think we > can move it to xdg_shell, since it's really a per-client thing, not > a per-surface thing. > > - set_transient_for is not a great name. I know it comes from ICCCM, > but I wonder if we can find a better name. If it's just stacking, > then maybe just set_aboe? > It specifies a parent-child relationship. In mutter, we'll use this to attach modal dialogs to their parent windows, for instance. > - protocol for server-initiated move/resize (eg mod+drag or kb > resize?), probably similar to what we do for server side requestsed > maximize. > What protocol is there here? > - not sure configure needs the edges flag anymore, in the cases where > the server requests a change to the surface size, the server > typically also knows where the window should go. I think the flag > dates back to before the configure callback and the shell didn't > have a way to intercept the attach. We relied on the client > passing the right dx/dy, but now the shell gets the configure > callback and can keep the right and top edges in place in case > we're resizing from bottom+left. This should also fix xwayland > resizing from top or left side. > > - we now have set/unset/request_set/request_unset for fullscreen and > maximize, and we'll add minimized, probably tiled_left/right. This > is going to explode into a large number of requests and events all > with the same structure and flow as the maximized flow we've > discussied this week. We should consider a more generic approach: > > - set(MAXIMIZED), unset(MAXIMIZED) requests, where maximized is an > enum, that is, we don't allow set(MAXIMIZED | FULLSCREEN), but > since it's all atomic under wl_surface.commit, > set(MAXIMIZED)+set(FULLSCREEN) will have the intended effect > (ignore that MAXIMIZED and FULLSCREEN doesn't make sense). > > - requet_set(MAXIMIZED) and request_unset(MAXIMIZED) to let the > server intiate the transition. > My hesitation with the enum would be people adding their own extensions to the enum without standardizing anything... ... if that's something we want (for e.g. tiled-top, tiled-bottom), then we should look at maybe having strings as states? Kristian > ... snip ... > > _______________________________________________ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jasper
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel