[compiz] Patch to wobbly snap for outputs

[Mike Cook]

On Tue, Dec 12, 2006 at 10:03 AM, David Reveman wrote: 
>> Sorry, by "inner struts" I was trying to refer to those on the inside edge 
>> between two outputs.  Say I have 2 monitors, and I have a vertical dock
>> covering the right edge of the left monitor, or the left edge of the right
>> monitor--  basically down the middle of the screen.  Those type seem to
>> be currently ignored.
> 
> OK, lets find out why they are ignored then. What struts are those
> vertical dock windows using? If those windows are not just setting any
> strut hints, then it's not much we can do.

I'll try to look into the struts calculations also, and hopefully understand what
is going on...  They do work when they're on the "outer" edges of the entire
screen, just not "inner" output edges.  I assume there are struts as metacity
honors them for both maximize and snap edges.

>> 2-  A dock may cover the top or bottom of only one output.  That strut should
>>    not be considered when snapping or maximizing on a different output.
> 
> Why this behavior?

With two screens (different rez 1600x1200 & 1280x1024, but that's not the
issue) if I place a Gnome panel on the top of the left output it only covers the
width of that output, as it should.  The problem is that when moving a window
on the right output (which has no panel) it has a "phantom" snap near the top
because of the bottom edge of that panel on the left output.

>> 3-  In the case of the total screen's workarea we should ignore those in #1 
>>    and clip to those in #2 to have the largest total area (at least until the 
>>    workarea hint can handle multiple regions, or whatever other solution the
>>    spec comes up with).
> 
> The screen workarea could be the current outputs workarea and be updated
> as the current output changes. This might confuse desktop windows,
> though.

I tried that and the only obvious problem I saw was that the all desktop icons
kept jumping to the current output.  It did, however, solve the problem of apps
(especially Java) which tried to place their windows in the screen center.

>> 4-  Also, say you have two or three panels across the top of an output.  You
>>    wouldn't want to snap to each one separately, but just to the lowest one,
>>    which should be what the output workarea calculation would give you.
> 
> I would want to snap to each one separately and have windows placed
> smarter then just in the workarea rectangle. Windows should still be
> maximized to the workarea rectangle, of course.

In my testing if I had two short (25px) panels covering the entire width which
were stacked together at the top of an output, if it snaps to both I sometimes
got bouncing of the window edge between the two panels since they were so
close.  That's why it seemed better to snap to just the innermost edge.

>> So, in the end, that's why I was thinking that each output workarea would be
>> the best region to snap to, if they include calculations for all the struts at
>> any edge within that output.  That then also covers snapping to the output
>> edges (strut or not).  Sorry for the long response... ;)
> 
> There's clearly some more work to be done here and I appreciate your
> help with getting this right.

I'm always glad to help, though it's mostly selfish desire to make it work for me.
I still think using the output workareas would be best since we can make all the
right strut calculations and anything else to get it right, and then just use the
end result in all of these places to be consistent (maximize, snap, etc).

Oh, and thanks again for your great work, David!

...MC