[PATCH] shell: Enhance the basic random positioning algorithm

Kristian Høgsberg hoegsberg at gmail.com
Mon Aug 13 10:38:55 PDT 2012

On Mon, Aug 13, 2012 at 1:20 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> 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.

The compositor is not going to discard part of the buffer like that.
If the window is fullscreen or maximized or maximized
vertically/horizontally, the client has to know that and render a
buffer that works for that window state.


More information about the wayland-devel mailing list