Kristian Høgsberg wrote:
That's a nice improvement indeed. I've committed it since it's obviously a step forward, but I think we could use the input region extents for placement. There's been talk of a outline region or such, something to define the "edge" of the window for snapping and placement, but I haven't yet been able to think of a case where that's different from the input region. So we can just use the input region for now, and if a case for an outline region comes up, we can add that then. Kristian
If this is what I was trying to descibe, this region I want is the "inside" of the edge. If you imagine a Windows95-style window but with a shadow, this region does not include the shadow and does not include the 3 or 4 pixels that are the rounded-looking "edge". However it includes what X would call the "contents" and also the "flat" part of the "titlebar".
This would allow maximization to be done by the shell choosing a surface size that is larger than the output. The edges and shadows would be drawn in this extra area that is clipped by the compositor. The shell needs to know this region so it can choose this larger size.
The main reason for this is so that maximize-vertical can be supported and produces the same vertical size as full-screen maximize. It is also useful as a snap-to edge when moving windows, assuming they can be dragged off the screen at all.
Because it seems wasteful for clients to allocate and draw invisible window edges and shadows, I also propose that the shell tell the client both the desired surface size and the bounding box of this region. Most drawing api's can easily translate and clip off the unnecessary graphics, and more intelligent clients can actually skip the graphics or adjust the shading on still-visible ones.
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
