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

Kristian
>

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



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