Re: Additional issues to address for the constraints_experiments branch?

[Elijah Newren <newren gmail com>]

On 11/15/05, Soren Sandmann Pedersen <sandmann redhat com> wrote:
> I am probably missing something, but what about:

Well, I feel kind of sheepish for not being aware of GdkRegion.  :)

> - Generate a GdkRegion "strut_region" of all the struts
> - rects = strut_region.get_rectangles();
> - for each r in rects:
>        add r.x and r.x + r.width to list of x coordinates unless they
> are there already
>        add r.y and r.y + r.height to list of y coordinates unless they
> are there already
> - for each x in x coordinates
>        for each y in y coordinates
>             add (x, y) to list of intersection points

That's going to generate some weird (x,y) points outside the domain;
is that intentional?

> - for each point in list of intersection points
>        for each corner of the window
>               if positioning the window corner at the point doesn't
> conflict,

What do you mean by "conflict"?  !gdk_region_rect_in ?

>               then we have found a possible window position
> - look at all the generated window positions, and take the one closest
> to the desired
>   position. Then move the corner that was attached to an intersection
> point as far
>   towards the desired position as possible.

I don't fully understand what you mean here.  From what I think I
understand (correct me if I'm wrong), it looks like you're only
looking at corners of the window matching the (x,y) points of corners
of rectangles from the region and thus it appears that you might move
the window further than needed (you may only need to move it
vertically to get it back in the region, but the window corners may
not vertically align with corners of rectangles of the region).

> So it's O(n^2) in the number of struts, but completely simple and
> guaranteed to find the optimal solution if a solution exists at all.

Right, it looks like using GdkRegion might allow me to get rid of
  meta_rectangle_get_minimal_spanning_set_for_region()
  meta_rectangle_expand_region()
  meta_rectangle_contained_in_region()
  meta_rectangle_clip_to_region()

(of which I don't really need the fourth anymore, and the second and
third are kind of trivial anyway).  However, I would have to rewrite
some new functions in terms of GdkRegion that might not be as easy to
do as they are for these "minimal spanning sets":
  meta_rectangle_shove_into_region()
  meta_rectangle_clamp_to_fit_into_region()
  meta_rectangle_could_fit_in_region()

It looks like you were explaining how to do the first of these in
terms of a GdkRegion (though I didn't quite follow and there is an
extra requirement that sometimes I am only interested in the shortest
distance in a certain direction, even if it isn't the shortest
distance overall).

So, it looks possible, but we do already have something that works[1]
and does the same thing (and isn't O(n^2) per meta_window_constrain()
call, not that it's likely to matter).  Maybe transitioning to
GdkRegion later makes sense (perhaps when we become more worried about
shaped windows?).

Cheers,
Elijah

[1] Note that the bug Ray found last night was actually with the edge
resistance code and not the constraints stuff.  I implemented edge
resistance too because fixing bug 122196, bug 143145, bug 136307, bug
156699, and bug 142016/143784 made screen/xinerama edges feel special
and made it weird when users moving windows didn't do something
different at those edges.  Besides, edge resistance is just cool.