Re: CENTER_ALWAYS behaviour

[Havoc Pennington <hp redhat com>]

Tim Janik <timj gtk org> writes: 
> you're right in the above comment in that we couldn't recenter upon
> every size change, e.g. if the window manager gave us a new size (i.e.
> size changes from configure events), but size changes due to widget
> tree layout changes need to still trigger the recentering code.
> 

Investigating a bit, the current code is intended to do as you
describe. It does constrain position if our configure request changes:

  if (configure_request_pos_changed ||
      configure_request_size_changed ||
      info->position_constraints_changed)
    {
      /* We request the constrained position if:
       *  - we were changing position, and need to clamp
       *    the change to the constraint
       *  - we're changing the size anyway
       *  - set_position() was called to toggle CENTER_ALWAYS on
       */

      gtk_window_constrain_position (window,
                                     new_request.width,
                                     new_request.height,
                                     &new_request.x,
                                     &new_request.y);
      
      /* Update whether we need to request a move */
      if (info->last.configure_request.x != new_request.x ||
          info->last.configure_request.y != new_request.y)
        configure_request_pos_changed = TRUE;
      else
        configure_request_pos_changed = FALSE;
    }
  
The configure request (once we're mapped) comes from
widget->allocation not widget->requisition, to avoid loops. However it
is constrained to geometry hints which should change with a new
requisition. So for a !resizeable window, the configure request should
reliably change as the window requisition changes, that is I would
expect configure_request_size_changed to be TRUE in the above code.
I'm not sure why it isn't. For a resizeable window, CENTER_ALWAYS is
just total nonsense, but if the requisition grows larger than the
current allocation I think we'd still do the centering.

Havoc