[compiz] Patch to wobbly snap for outputs

[Mike Cook]

On Tue, Dec 12, 2006 at 12:48 PM, David Reveman wrote: 
>>> 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.

If I'm reading it right in gnome-panel source in panel-struts.c it appears that
the panels get their strut size set to 0 if they're not at the outer edges of the
screen, which would seem to be why they're being ignored.  The start/end still
get set, though.  Possibly we could specially handle a window with struts with a
size of 0 and start/end set by looking at the window geometry...?

I haven't found how metacity and kwin deal with it, yet, but it looks like they both
have their own problems.  In quick tests metacity seems to not snap to an "inner"
strut, whereas kwin does but constrains Y at the top for a strut on another output,
so they're not perfect either.  I thought they handled better in previous tests, so
I'll try more tests later.

>> 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.
> 
> That shouldn't happen with the current code as long as the strut hints
> are set correctly by the gnome panel.

You're right, the "phantom" snap is fixed, so just the "inner" strut issue remains.

> That seems like a general problem with the snapping code and you'll get
> this with other windows too so fixing it by maybe ignoring edges close
> to other edges or something like that might be a better solution.

Agreed.

> I'm still in favor of using an exact region for snapping and
> placement. :- ) I would hate to see windows snap to invisible edges.

And I think you've convinced me.  ;)  I wasn't taking into account the partial
struts.  So, the last problem I'm aware of now is just the "inner" struts.  I saw
some workarounds in the kwin code related to making sure it accounts for
which output a strut is on, so maybe they might be an example.  I'll check...

...MC