[compiz] Patch to wobbly snap for outputs

David Reveman davidr at novell.com
Mon Dec 18 17:18:53 PST 2006


On Mon, 2006-12-18 at 16:10 -0700, Mike Cook wrote:
> 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

I have now pushed out some code to handle this properly. Here's what I
think is the correct way to include each strut:

(a window strut edge is valid if it's within the destination box)

1. left_strut = 0.
2. right_strut = box_max_x.
3. update left_strut if left window strut edge is valid.
4. update right_strut if right window strut edge is valid.
5. horizontal struts are only valid if they are not overlapping,
left_strut must be less than right_strut. if they are not valid go to 6.
5.1. update max_left_strut if left_strut is greater.
5.2. update min_right_strut if right_strut is less.

6. top_strut = 0.
7. bottom_strut = box_max_y.
8. update top_strut if top window strut edge is valid.
9. update bottom_strut if bottom window strut edge is valid.
10. vertical struts are only valid if they are not overlapping,
top_strut must be less than bottom_strut. if they are not valid go to
11.
10.1. update max_top_strut if top_strut is greater.
10.2. update min_bottom_strut if bottom_strut is less.

11. done.


This will allow floating struts while still handling overlapping struts
like what kicker sets properly.

Have a look at the code I put in screen.c, it's simple and hopefully
very easy to understand for anyone who wants to know what's going on
there.

-David



More information about the compiz mailing list