Re: constraints_experiments is ready

[Havoc Pennington <hp redhat com>]

On Thu, 2005-11-17 at 11:27 -0700, Elijah Newren wrote:
> > Pretty sure it's Owen, or "the gtk team" - anyway it's copied from gdk.
> 
> For both meta_rectangle_intersect() and meta_rectangle_equal()?

I think so. _equal() is so trivial maybe I just made it up.

> > I think we're just using different terminology.
> >
> > window->rect.x would be the X server position of the window relative to
> > its parent (frame or root window)
> >
> > On initial map of a NW gravity window we are going to create a window
> > frame and put it at the old window->rect.x and move window->rect.x by
> > the frame offset, but window->rect.x itself is never the position of the
> > frame because when we add the frame we change window->rect.x to be
> > relative to the frame (and we move the window to the right by the width
> > of the left frame edge)
> >
> > i.e. it's an invariant that window->rect.x is the server-side static
> > gravity position of the window relative to the window's parent (frame or
> > root)
> 
> Re-read and analyze the algorithm you just described.  The effect is
> that the x & y specified by the app corresponds to the location of the
> frame window, rather than the internal/app window.  My comment was
> just trying to explain that.

I agree the effect is the same ;-)

All I'm saying is that to me window->rect.x is never the position of the
frame window, conceptually. It does happen to map to that for the moment
in time your comment applies to, but just because we interpret the
window's current position as a configure request with NorthWestGravity
at that moment in time, and NorthWestGravity configure requests mean
"treat the requested x,y as the NW corner of the frame window"

> Ah, makes sense.  And now that I grep over the code again it appears I
> looked into this before as well.  The session saving uses
> meta_window_get_geometry() which uses
> meta_window_get_gravity_position() in order to figure out the location
> to save.  So hard-coding NorthWestGravity in the call from
> meta_window_apply_session_info() to meta_window_move_resize_internal()
> was indeed wrong and just happened to have been corrected by the fact
> that adjust_for_gravity() ignores the gravity passed to
> meta_window_move_resize_internal() and instead uses the size hints
> gravity.

Well be fair to me here, I think I did that on purpose ;-) the bug was
just that I was doing this convoluted:

 move_resize_internal ( int gravity, boolean
ignore_gravity_arg_and_use_other_gravity)

so where NW gravity was passed in for the session it was supposed to be
ignored, in a rube goldberg way.

> > One way we might think about it is that the gravity arg to
> > move_resize_internal should be a gravity *OR* "this is from the
> > application, use size_hints.gravity"
> 
> If it's from the application (and it's not a _NET_MOVERESIZE_WINDOW
> message that specifies its own gravity), why not just have the
> application pass size_hints.gravity to
> meta_window_move_resize_internal()?  It's exactly what we need in all
> three cases anyway (configure request, new window, and session
> restore; which occur from meta_window_configure_request(),
> meta_window_new_with_attrs(), and meta_window_apply_session_info()
> respectively).

Right, I get it now and agree. There's no point having:
"boolean ignore_gravity_arg_and_use_other_gravity"
when we can just pass in the right gravity arg.

Havoc