[PATCH 01/16] xdg_shell: Adding a new shell protocol.
Jasper St. Pierre
jstpierre at mecheye.net
Sat Nov 30 19:10:21 PST 2013
On Fri, Nov 29, 2013 at 7:09 PM, Kristian Høgsberg <hoegsberg at gmail.com>wrote:
> 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
> toolbox type.
>
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).
> > > - 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.
>
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.
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.
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.
> > - 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.
>
> Kristian
>
> > 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
>
--
Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131130/4eaa2837/attachment.html>
More information about the wayland-devel
mailing list