[PATCH 01/16] xdg_shell: Adding a new shell protocol.
hoegsberg at gmail.com
Fri Nov 29 16:09:07 PST 2013
On Fri, Nov 29, 2013 at 06:41:59PM -0500, Jasper St. Pierre wrote:
> On Fri, Nov 29, 2013 at 5:43 PM, Kristian Høgsberg <hoegsberg at 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.
Saying it's a parent-child relationship doesn't really help - it's a
generic conecept and it's not clear what it might mean in this
context. Which is why I'd prefer something more specific. And it
sounds like there's something we're not capturing here: dialogs that
are transient_for will be attached by mutter, but floating toolboxes
are also transient_for but doesn't get attached. I'm guessing mutter
also looks at wether the window in question is a dialog type or a
> > - 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?
When the server initiates a move or resize, the client just sees its
pointer focus disappear and then potentially later come back when the
move/resize is done. For move, I don't know if we need anything, but
for resize, would could have a "request_resize(edges)" event from the
server that asks the client to trigger a resize. The client can
ignore if it doesn't feel like resizing or start a resize by sending
the resize request. This gives the client a more structured way to
decline a resize and wm doesn't try to resize a non-resizable window.
> > - 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?
Yeah, strings could work.
> ... snip ...
> > > _______________________________________________
> > > wayland-devel mailing list
> > > wayland-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
More information about the wayland-devel