Re: [RFC] _NET_WORKAREA and Xinerama

[Rob Adams <robadams ucla edu>]

Perhaps we can represent the constraints as a linear program and find
feasible window positions using the simplex algorithm.

On Fri, 2003-03-14 at 22:41, Havoc Pennington wrote:
> 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
>