[compiz] Patch to wobbly snap for outputs

[Mike Cook]

On Mon, Dec 18, 2006 at  2:42 PM, David Reveman wrote: 
>> As I understand the spec, and verified in testing, the design is for
>> the _NET_WM_STRUT_PARTIAL hint (and the fallback _NET_WM_STRUT) to
>> define each strut as only a distance from the screen edge, and the
>> start/end (added in _PARTIAL) specifies how much of that edge it takes
>> (instead of defaulting to the entire screen height or width).  The
>> starting edge is always an edge of the screen.
> 
> Yes, you're right. leftX1 will always be 0 and leftX2 will always be
> screenW but the code in computeWorkareForBox doesn't assume so and it
> shouldn't. leftX1 always being 0 or not doesn't matter, what I mentioned
> above should still be valid and the
> "if (y1 < pBox-  >y2 && y2 > pBox-  >y1 && x2 < pBox-  >x2)"
> check should be all we need to get the left edge correct.

While that check will work for output workareas, I don't think it will
handle the screen workarea box where the strut should be ignored if it
extends over an entire output but still ends within the box.  In the two-
screen example with a panel on the left edge of the right output, the
screen workarea would be shifted completely off the left output (as it is
today if I use kicker with Compiz).  That's why I was thinking we'd need
to add more to the check.

If we don't assume a strut starts at screen edge (which implies a change to
the spec), then we'd need to decide if we want to allow floating windows
to set struts that affect workarea.  My latest patch will already allow the
strut if it overlaps the edge of the box (regardless of the starting at screen
edge or not), but would need to be improved to handle a floating window
depending on that decision.  I'd expect we'd want to ignore a floating
window that doesn't touch the box edge...  They could still be included
in place, move, or snap operations.

...MC