Re: CENTER_ALWAYS behaviour

[Havoc Pennington <hp redhat com>]

Tim Janik <timj gtk org> writes:
> at some point though (and not always) the resizing/recentering might
> get stuck, from then on, the label alignment is screwed and further
> resizes only occour only to the right.
> 

Reproduced with Sawfish, but I can't reproduce with twm or
Metacity. (With Metacity you have to set GDK_HINT_USER_POS before it's
testable.) I believe this is because Sawfish is really slow to handle
configure requests, and that triggers just the right interaction with
GTK.

Theory on what's happening with Sawfish is that the following results
in the size never changing, because the new size is always equal to
either the allocation or the last configure request, since gle is
alternating between two different sizes:

   if ((info->last.configure_request.width != new_request.width ||
       info->last.configure_request.height != new_request.height) &&
      (widget->allocation.width != new_request.width ||
       widget->allocation.height != new_request.height))
    configure_request_size_changed = TRUE;

For the faster window managers, it's more common that the last request
and the current allocation are identical (since we got the notify back
quickly, before we changed our mind on the request), so it's more
common that the new request is different from both. i.e. with Sawfish
there is a longer interval where our last request differs from our
current allocation. Speeding up GTK might "catch up" to the faster
window managers and trigger the bug with them as well.

In any case, the result of size_changed = FALSE is that we don't
constrain position:

  if (configure_request_pos_changed ||
      configure_request_size_changed ||
      info->position_constraints_changed)
    {
      gtk_window_constrain_position (window,


Thus we never constrain position as long as the alternation continues.
If you move the mouse over a different widget, getting a different
size other than the two being alternated between, then the dialog is
centered again.

Since size_changed = FALSE, the only reason GTK is sending configure
requests at all is that hints_changed = TRUE, due to the requisition
changing.

One simple fix is to constrain position if hints_changed = TRUE, since
this makes things more consistent (we constrain position if we're
going to send configure requests). I think this may unearth other
bugs, but it's probably the right fix.

I'll check in the appended patch.

Havoc

+++ gtkwindow.c 2001/08/18 17:01:31
@@ -3514,8 +3514,15 @@ gtk_window_move_resize (GtkWindow *windo
    * app author is thinking.
    */
 
+  /* This condition should be kept in sync with the condition later on
+   * that determines whether we send a configure request.  i.e. we
+   * should do this position constraining anytime we were going to
+   * send a configure request anyhow, plus when constraints have
+   * changed.
+   */
   if (configure_request_pos_changed ||
       configure_request_size_changed ||
+      hints_changed ||
       info->position_constraints_changed)
     {
       /* We request the constrained position if: