changeset 2195:23d90a805259

[xemacs-hg @ 2004-07-31 12:03:05 by malcolmp] Fix cases where GTK scrollbars are left in the middle of a frame.
author malcolmp
date Sat, 31 Jul 2004 12:03:05 +0000
parents 9b40b475f33f
children 4c063404364a
files src/ChangeLog src/frame-gtk.c src/gtk-xemacs.c src/scrollbar-gtk.c
diffstat 4 files changed, 86 insertions(+), 33 deletions(-) [+]
line wrap: on
line diff
--- a/src/ChangeLog	Fri Jul 30 21:50:23 2004 +0000
+++ b/src/ChangeLog	Sat Jul 31 12:03:05 2004 +0000
@@ -1,3 +1,18 @@
+2004-07-27  Malcolm Purvis  <malcolmp@xemacs.org>
+
+	* frame-gtk.c (gtk_make_frame_visible):
+	* frame-gtk.c (gtk_make_frame_invisible): Use map/unmap instead of
+	show/hide.  This is what X uses and is prevents previously hidden
+	widgets from suddenly reappearing.
+	* gtk-xemacs.c (gtk_xemacs_paint):
+	* gtk-xemacs.c (gtk_xemacs_draw):
+	* gtk-xemacs.c (gtk_xemacs_expose): Only operate if the widget is
+	drawable.
+	* scrollbar-gtk.c (gtk_update_scrollbar_instance_status): Force
+	size and location changes so that they can be seen before the next
+	idle event.  Without this rapid changes to scrollbar properties
+	are not seen.
+
 2004-07-07  Malcolm Purvis  <malcolmp@xemacs.org>
 
 	* console-gtk-impl.h:
--- a/src/frame-gtk.c	Fri Jul 30 21:50:23 2004 +0000
+++ b/src/frame-gtk.c	Sat Jul 31 12:03:05 2004 +0000
@@ -1271,7 +1271,7 @@
 static void
 gtk_make_frame_visible (struct frame *f)
 {
-    gtk_widget_show_all (FRAME_GTK_SHELL_WIDGET (f));
+    gtk_widget_map (FRAME_GTK_SHELL_WIDGET (f));
     gtk_raise_frame_1 (f, 0);
 }
 
@@ -1279,7 +1279,7 @@
 static void
 gtk_make_frame_invisible (struct frame *f)
 {
-    gtk_widget_hide (FRAME_GTK_SHELL_WIDGET (f));
+    gtk_widget_unmap(FRAME_GTK_SHELL_WIDGET (f));
 }
 
 static int
--- a/src/gtk-xemacs.c	Fri Jul 30 21:50:23 2004 +0000
+++ b/src/gtk-xemacs.c	Sat Jul 31 12:03:05 2004 +0000
@@ -342,8 +342,10 @@
 {
     GtkXEmacs *x = GTK_XEMACS (widget);
     struct frame *f = GTK_XEMACS_FRAME (x);
-    redisplay_redraw_exposed_area (f, area->x, area->y, area->width,
-				   area->height);
+
+    if (GTK_WIDGET_DRAWABLE (widget))
+      redisplay_redraw_exposed_area (f, area->x, area->y, area->width,
+				     area->height);
 }
 
 static void
@@ -359,32 +361,35 @@
        gtk_fixed_paint() directly, which clears the background window,
        which causes A LOT of flashing. */
 
-    gtk_xemacs_paint (widget, area);
+  if (GTK_WIDGET_DRAWABLE (widget))
+    {
+      gtk_xemacs_paint (widget, area);
 
-    children = fixed->children;
+      children = fixed->children;
 
-    while (children)
-      {
-	child = (GtkFixedChild*) children->data;
-	children = children->next;
-	/* #### This is what causes the scrollbar flickering!
-	   Evidently the scrollbars pretty much take care of drawing
-	   themselves in most cases.  Then we come along and tell them
-	   to redraw again!
+      while (children)
+	{
+	  child = (GtkFixedChild*) children->data;
+	  children = children->next;
+	  /* #### This is what causes the scrollbar flickering!
+	     Evidently the scrollbars pretty much take care of drawing
+	     themselves in most cases.  Then we come along and tell them
+	     to redraw again!
 
-	   But if we just leave it out, then they do not get drawn
-	   correctly the first time!
+	     But if we just leave it out, then they do not get drawn
+	     correctly the first time!
 
-	   Scrollbar flickering has been greatly helped by the
-	   optimizations in scrollbar-gtk.c /
-	   gtk_update_scrollbar_instance_status (), so this is not that
-	   big a deal anymore.
-	*/
-	if (gtk_widget_intersect (child->widget, area, &child_area))
-	  {
-	    gtk_widget_draw (child->widget, &child_area);
-	  }
-      }
+	     Scrollbar flickering has been greatly helped by the
+	     optimizations in scrollbar-gtk.c /
+	     gtk_update_scrollbar_instance_status (), so this is not that
+	     big a deal anymore.
+	  */
+	  if (gtk_widget_intersect (child->widget, area, &child_area))
+	    {
+	      gtk_widget_draw (child->widget, &child_area);
+	    }
+	}
+    }
 }
 
 static gint
@@ -394,14 +399,17 @@
     struct frame *f = GTK_XEMACS_FRAME (x);
     GdkRectangle *a = &event->area;
 
-    /* This takes care of drawing the scrollbars, etc */
-    parent_class->expose_event (widget, event);
+  if (GTK_WIDGET_DRAWABLE (widget))
+    {
+      /* This takes care of drawing the scrollbars, etc */
+      parent_class->expose_event (widget, event);
 
-    /* Now draw the actual frame data */
-    if (!check_for_ignored_expose (f, a->x, a->y, a->width, a->height) &&
-	!find_matching_subwindow (f, a->x, a->y, a->width, a->height))
-      redisplay_redraw_exposed_area (f, a->x, a->y, a->width, a->height);
-    return (TRUE);
+      /* Now draw the actual frame data */
+      if (!check_for_ignored_expose (f, a->x, a->y, a->width, a->height) &&
+	  !find_matching_subwindow (f, a->x, a->y, a->width, a->height))
+	redisplay_redraw_exposed_area (f, a->x, a->y, a->width, a->height);
+      return (TRUE);
+    }
 }
 
 Lisp_Object
--- a/src/scrollbar-gtk.c	Fri Jul 30 21:50:23 2004 +0000
+++ b/src/scrollbar-gtk.c	Sat Jul 31 12:03:05 2004 +0000
@@ -221,6 +221,21 @@
 	      gtk_widget_set_usize (wid,
 				    pos_data->scrollbar_width,
 				    pos_data->scrollbar_height);
+
+	      /*
+		UGLY! UGLY! UGLY!  Changes to wid->allocation are queued and
+		not performed until the GTK event loop.  However, when the
+		fontlock progress bar is run, the vertical scrollbar's height
+		is change and then changed back before events are again
+		processed.  This means that the change back is not seen and
+		the scrollbar is left too short.  Fix this by making the
+		change manually so the test above sees the change.  This does
+		not seem to cause problems in other cases.
+	       */
+
+	      wid->allocation.width = pos_data->scrollbar_width;
+	      wid->allocation.height = pos_data->scrollbar_height;
+
 	      modified_p = 1;
 	    }
 
@@ -232,6 +247,21 @@
 			      wid,
 			      pos_data->scrollbar_x,
 			      pos_data->scrollbar_y);
+
+	      /*
+		UGLY! UGLY! UGLY!  Changes to wid->allocation are queued and
+		not performed until the GTK event loop.  However, when the
+		fontlock progress bar is run, the horizontal scrollbar's
+		position is change and then changed back before events are
+		again processed.  This means that the change back is not seen
+		and the scrollbar is left in the wrong position.  Fix this by
+		making the change manually so the test above sees the change.
+		This does not seem to cause problems in other cases.
+	       */
+
+	      wid->allocation.x = pos_data->scrollbar_x;
+	      wid->allocation.y = pos_data->scrollbar_y;
+
 	      modified_p = 1;
 	    }