[PATCH 01/16] xdg_shell: Adding a new shell protocol.

Jasper St. Pierre jstpierre at mecheye.net
Fri Nov 29 15:41:59 PST 2013

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.

>  - 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?


... 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131129/afca2db9/attachment-0001.html>

More information about the wayland-devel mailing list