[compiz] Patch to wobbly snap for outputs

[Mike Cook]

On Fri, 2006-12-11 at 21:32 -0700, David Reveman wrote:
> After looking at this I found the correct solution to be to just snap to
> window struts instead of any workarea. I've pushed out changes that
> should take care of this. I don't have access to a multi-head setup
> right now so I can't verify that it works OK. Please give it a try.

Hm, somebody will have to donate a couple extra monitors...  ;)  After a quick
first test on a single head machine I think there's a typo, as it seems to be
ignoring the struts and just snapping to screen edges for me.  Also, I'm not
sure if the struts are the best option-- more on that below...

> I've included a few more window types in snapping. However, including
> dock windows is probably not a good idea. Sometime windows with dock
> type and below state are used for windows that shouldn't have any
> decorations and stick to the desktop. We don't want to snap to those.

Ah, yeah, I wasn't sure if dock type might be used like that.

> > I personally think we should include these "inner" struts when calculating the
> > workarea for each output (which also helps window maximizing), and only
> > ignore them in the screen workarea case (for the _NET_WORKAREA hint).
> 
> What do you mean by "inner" struts? Each workarea rectangle should be
> the maximum rectangle that doesn't intersect any struts. If that's
> currently not the case, it should be fixed.

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.

> If the workarea isn't good enough for a plugin it should instead look at
> the strut hints for each window like the wobbly plugin is now doing. We
> can add a region to the output struct that is the output area minus all
> window struts if that turns out useful for plugins.

I can't think of any time the output's workarea wouldn't work, as however that is
calculated we should probably use it to be consistent.  Here are the issues I
ran into as I was trying to work on this:
1- Struts that are on those "inner" edges like I described before are currently
   ignored in the output workarea calculation.  So, for instance, a window will
   maximize to the output edge under that dock.
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.
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).
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.
5- And finally, in the patch I was intending that a window also snaps to the
   edges of each output, which is the current behavior that I get with metacity,
   I believe.

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

...MC