I give up. I can't work out what the purpose of the call to

gtk_container_dequeue_resize_handler in request_resize() was;
everything seems to work fine without it. So I'm removing the
nonportable GTK 2 instance of it, and if anything ever goes wrong as
a result then I'll at least find out what the problem was.

[originally from svn r7957]

diff --git a/unix/GTK2.TODO b/unix/GTK2.TODO
index 77de23d5ed2fd41680b8d91439ec1a0b111ae84c..efbd496a9e6ff57f0889017f13337e2d6383523b 100644 (file)
--- a/unix/GTK2.TODO
+++ b/unix/GTK2.TODO
@@ -10,14 +10,6 @@ Things to do before deciding a merge is feasible:
    selected by default. Then again, perhaps keeping fixed as the
    default is more traditional. Hmm.
 
- - The call to _gtk_container_dequeue_resize_handler wants
-   revisiting, and preferably removing in favour of a cleaner way to
-   do the job.
-    + trouble with this is that I have no idea what it's actually
-      doing. Perhaps the thing to do is to debug through the GTK1
-      version and see when it gets called and what happens if I take
-      it out?
-
  - gtkcols.c is currently a minimal-work GTK2 port of my original
    GTK1 implementation. Someone should go through it and compare it
    to a real GTK2 container class, to make sure there aren't any

diff --git a/unix/gtkwin.c b/unix/gtkwin.c
index 5e4c694686ded2127ea8809197cef7f2f8f74a45..51a867e1fa88359da3a4d7095681f0da2f59d638 100644 (file)
--- a/unix/gtkwin.c
+++ b/unix/gtkwin.c
@@ -1350,12 +1350,28 @@ void request_resize(void *frontend, int w, int h)
      */
 #if GTK_CHECK_VERSION(2,0,0)
     gtk_widget_set_size_request(inst->area, area_x, area_y);
-    _gtk_container_dequeue_resize_handler(GTK_CONTAINER(inst->window));
     gtk_window_resize(GTK_WINDOW(inst->window),
                      area_x + offset_x, area_y + offset_y);
 #else
     gtk_widget_set_usize(inst->area, area_x, area_y);
     gtk_drawing_area_size(GTK_DRAWING_AREA(inst->area), area_x, area_y);
+    /*
+     * I can no longer remember what this call to
+     * gtk_container_dequeue_resize_handler is for. It was
+     * introduced in r3092 with no comment, and the commit log
+     * message was uninformative. I'm _guessing_ its purpose is to
+     * prevent gratuitous resize processing on the window given
+     * that we're about to resize it anyway, but I have no idea
+     * why that's so incredibly vital.
+     * 
+     * I've tried removing the call, and nothing seems to go
+     * wrong. I've backtracked to r3092 and tried removing the
+     * call there, and still nothing goes wrong. So I'm going to
+     * adopt the working hypothesis that it's superfluous; I won't
+     * actually remove it from the GTK 1.2 code, but I won't
+     * attempt to replicate its functionality in the GTK 2 code
+     * above.
+     */
     gtk_container_dequeue_resize_handler(GTK_CONTAINER(inst->window));
     gdk_window_resize(inst->window->window,
                      area_x + offset_x, area_y + offset_y);