I feel configure events and requests are messed up

[Giovanni Campagna]

Il giorno gio, 08/09/2011 alle 12.45 -0700, Bill Spitzak ha scritto:
> Kristian Høgsberg wrote:
> 
> >> You want a concrete example? Consider edge tiling: in that mode, the
> >> window is not resizable, and attempts to programmatically resize it
> >> should be cached and reapplied when the window is desnapped. Shall we
> >> tell the client it is edge tiled? If we go that road, we end up with
> >> EMWH, trying to specify all possible window states...
> > 
> > Yes, the client needs to know that it can't resize at that time.  You
> > can't force clients to behave a certain way by just clamping their
> > size, they have to understand that they're being displayed in a
> > certain way that means they can't currently resize freely.  Maybe
> > we'll need a flag in the configiure event that tells the client "be
> > this exact size" or maybe the client just needs to know that it's edge
> > tiled and cant try to resize.
> 
> This is why I think the resize messages from compositor to client need 
> to contain "edge" flags. There are 4, one for each edge. They indicate 
> that the edge should not be moved AND that any border on that edge is 
> not drawn (ie the window contents should extend to that side of the image).
> 
> Besides the use for tiled windows, the edge flags would also remove the 
> borders that are off the screen edge for edge-snapped and maximized 
> windows. There should also be a "title" flag to turn off the title bar 
> so full-screen can be supported. I think this is better than just 
> positioning the decorations outside the screen as it skips wasting time 
> drawing them, it works on edges of multiple screens (rather than the 
> decoration appearing on the adjacent screen), and I suspect Wayland will 
> be able to detect direct mapping of full-screen if the window is exactly 
> the size of the screen.
> 
> Clients are supposed to obey these flags and not request size+position 
> that moves them. Clients can disobey however and compositors should be 
> prepared for this, probably by clipping the surface and/or padding it 
> with solid rectangles to fill the requested area.
> 
> There currently is something called "edge" in the resize events but it 
> appears these are indicating what type of resize is being done, so that 
> if the client decides to alter the size they can move the corner the 
> user is dragging. These flags are also necessary. In fact if an edge 
> border is removed and these flags indicate the opposite edge is not 
> being dragged the client will have to move that edge so the window 
> contents remain the same size, as only it knows how thick the borders are.

Probably I forgot to mention, but at the Desktop Summit it was agreed
that client-side decorations won't happen, neither in KWin nor Mutter,
so the client does not need to worry about what edges it should draw.

This is because we both want applications that look and behave the same,
irrespective of the toolkit they were written with, and without having
"creative" app developers breaking the desktop environment conventions.
And it's really a matter of conventions: it would be hard to have
consistent client-side decorations without writing separate code for KDE
and for GNOME.
Another use case that was considered was the GNOME Shell overview, that
wants to decorate window differently than the workspace mode (will
happen only in 3.4, though), and the Plasma Mobile platform, in which
they want a different look and feel than the desktop shell.
The last case for server-side decorations is the larger resize area, as
implemented by Mutter 3.2. This cannot be part of the surface (or the
compositor will fail to position adjacent windows), but if we already
have compositor code drawing this "frame" and handling resizes on it, it
doesn't make sense to duplicate this client side.

Also, clients should have no say on positioning the window. Not only I
don't want windows to be able to move just under the pointer: placing
logic is one of the most complex winsys-independent parts of current
WMs, and it is clear we don't want to replicate this client-side.

Giovanni
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110908/59f4c6aa/attachment.pgp>