[compiz] Patch to wobbly snap for outputs

[David Reveman]

On Mon, 2006-12-18 at 20:12 -0700, Mike Cook wrote:
> On Mon, Dec 18, 2006 at 18:18, David Reveman wrote:
> > 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
> 
> >From what I've seen a window's struts are only set for a single side,
> depending on which edge it's on (regardless if it's the screen edge or an
> output edge).  So, a single window wouldn't overlap itself, as they would
> not set both left and right struts on the same window, not currently.
> You could have two separate panels that overlap in that way, which was
> what I was trying to describe with the diagrams a few replies back.
> Sorry if I didn't explain what I was seeing clearly...

OK, that's bad as there's then not really any way to determine if the
struts set by an application should be clipped by an output edge or not.
I guess we'll have to always clip by xinerama edges if that's what
applications assume we do. I don't want that workaround to be in the
computeWorkareaForBox function as it should only be applied to current
strut properties.

hm, I'm not a big fan of the _NET_WORKAREA and _NET_WM_STRUT_PARTIAL
hints anymore... not that I really ever were..

> 
> So, I think this latest update lends itself to a better solution for floating
> windows (if they set struts for more than one side), but I don't think it
> will handle the current case of a single kicker panel on the center edge
> between the two outputs (i.e., the screen workarea gets shifted entirely
> to the non-strut side of the panel).
> 
> I'll test some more once I get back to my multi-monitor machine, but
> that's what I'm thinking so far...  Cheers!

Well, I've pushed out some completely new code for computing the
workarea. I hopefully got it right this time but who knows... :)

-David