[compiz] Patch to wobbly snap for outputs

[David Reveman]

On Tue, 2006-12-12 at 11:25 -0700, Mike Cook wrote:
> 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.

That shouldn't happen with the current code as long as the strut hints
are set correctly by the gnome panel.

> 
> >> 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.

These apps place windows in the screen center when running other WMs
too, right?

> 
> >> 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.

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.

> 
> >> 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).

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

-David