Re: [RFC] _NET_WORKAREA and Xinerama

[Havoc Pennington <hp redhat com>]

On Fri, Mar 14, 2003 at 09:27:57PM -0800, Rob Adams wrote:
> I'm working on an implementation of this in metacity.  The thing that
> worries me right now is the "sqeeze play".
> 
> Two corner panels on opposite corners.  Put a window between them.  Then
> grow the corner panels until they meet in the middle.
> 
> I'm thinking that perhaps when two struts get two close to each other,
> the WM should merge them together.  This would result in the window
> "squirting" out when the struts are merged into one strut.  Is this the
> sort of behavior people had envisioned with regard to partial-width
> struts?

I'd envision that the window squirts out as soon as a strut overlaps
it.

i.e. the constraint on the window top is that it may not cross a strut. so
say we have:

======================================================== screen top

  strut A
----------        strut B
                 -------          strut C
                              --------------

             ----------------------
            |    top of window     |
            |                      |

I'm not sure what the right algorithm is. It is especially scary in
light of constraints.c already being scary. ;-)

The thing is that here the width and position of the window affects
what the constraints are. If the window is just moved straight up,
then it's constrained by the lowermost strut it overlaps, strut
C. However, if you move it left a bit OR resize it narrower, it would
ignore strut C.

Now, say you are doing a top-right resize; as you resize, the
constraints change. If you pull it right up to strut C, then move
left, as soon as you move out from under strut C you will be able to
pull it higher up. But once it's up alongside strut C, you should
either not be able to move it right, or when moving it right it should
autoshrink down so it's below strut C again.

This is maybe an interesting point; strut C seems to imply a partial
right strut because of the top strut. Perhaps an interesting thing to
consider when implementing.

Because the panel imposing strut C has both a top strut and a right
strut, effectively, there's this issue of which way to push the window
if you pull the panel out to be larger; do you push the window out of
the way to the left, or do you push the window down below the panel.

So the way constraints.c works is that you have to express the
constraints on window motion in terms of an equation that can be
solved for a size/position delta. So one way to approach this problem
is to figure out what that equation is for partial struts.

For example, and I'll probably screw this up, taking a
single-direction (North) resize to start, we have a y_delta; the
limits on the y_delta will be a function of the X position and width
of the window. If we say that function maxstrut(a,b) yields the max
strut height of the range of X coordinates [a,b], then you could say
something like:

 min_y_delta = maxstrut(current_x, current_x + width) - current_y

So North only is fairly easy, make it NorthWest or NorthEast and you
have to plug in an x_delta:

 width = current_width + x_delta

so:
  
  min_y_delta = maxstrut(current_x, current_x + (current_width + x_delta)) - current_y

which is the same as:

  y_delta >= maxstrut(current_x, current_x + (current_width + x_delta)) - current_y

or something. I'm already confused, it's 2am, and I don't remember
most of Calculus. ;-) 

Of course there's a max_y_delta, and a min/max_x_delta at the same
time, and it's probably very possible to get in a situation where you
can't satisfy all the constraints.

For people who remember more math than I do, maybe this isn't even
hard.

Other WMs use the "constraint solver" approach rather than the
constraints.c stuff, perhaps that approach could handle this more
easily.

Havoc