[compiz] Patch to wobbly snap for outputs
David Reveman
davidr at novell.com
Mon Dec 18 16:01:09 PST 2006
On Mon, 2006-12-18 at 18:10 -0500, Mike Cook wrote:
> On Mon, Dec 18, 2006 at 2:42 PM, David Reveman wrote:
> >> As I understand the spec, and verified in testing, the design is for
> >> the _NET_WM_STRUT_PARTIAL hint (and the fallback _NET_WM_STRUT) to
> >> define each strut as only a distance from the screen edge, and the
> >> start/end (added in _PARTIAL) specifies how much of that edge it takes
> >> (instead of defaulting to the entire screen height or width). The
> >> starting edge is always an edge of the screen.
> >
> > Yes, you're right. leftX1 will always be 0 and leftX2 will always be
> > screenW but the code in computeWorkareForBox doesn't assume so and it
> > shouldn't. leftX1 always being 0 or not doesn't matter, what I mentioned
> > above should still be valid and the
> > "if (y1 < pBox- >y2 && y2 > pBox- >y1 && x2 < pBox- >x2)"
> > check should be all we need to get the left edge correct.
>
> While that check will work for output workareas, I don't think it will
> handle the screen workarea box where the strut should be ignored if it
> extends over an entire output but still ends within the box. In the two-
> screen example with a panel on the left edge of the right output, the
> screen workarea would be shifted completely off the left output (as it is
> today if I use kicker with Compiz). That's why I was thinking we'd need
> to add more to the check.
Oh, I didn't think of that. Thanks. :)
>
> If we don't assume a strut starts at screen edge (which implies a change to
> the spec), then we'd need to decide if we want to allow floating windows
> to set struts that affect workarea. My latest patch will already allow the
> strut if it overlaps the edge of the box (regardless of the starting at screen
> edge or not), but would need to be improved to handle a floating window
> depending on that decision. I'd expect we'd want to ignore a floating
> window that doesn't touch the box edge... They could still be included
> in place, move, or snap operations.
I want all code in compiz that deals with struts (except the property
fetching of course) to support floating struts. We might want to use it
internally and in case it's decided that the EWMH spec should be
extended we don't have to modify any existing code to support that.
-David
More information about the compiz
mailing list