some bugs worked out.

comment cleanups
-timj

BUGS

@@ -1,136 +1,3 @@
-
-From timj@gimp.org Sat Jan 24 19:15:15 1998
-Date: Wed, 21 Jan 1998 00:37:31 +0100 (CET)
-From: Tim Janik <timj@gimp.org>
-To: Owen Taylor <owt1@cornell.edu>
-Cc: Gtk+ Devils <gtkdev@gimp.org>
-Subject: Crossing events (was: Re: sensitivity and states...)
-
-On Tue, 20 Jan 1998, Owen Taylor wrote:
-
-> 
-> > @@ -439,16 +445,27 @@ gtk_main_iteration_do (gboolean blocking
-> >            break;
-> > 
-> >          case GDK_ENTER_NOTIFY:
-> > -        case GDK_LEAVE_NOTIFY:
-> >            if (grab_widget && GTK_WIDGET_IS_SENSITIVE (grab_widget))
-> > -            gtk_widget_event (grab_widget, event);
-> > +            slist_cross_notify = g_slist_prepend (slist_cross_notify, grab_widget);
-> > +          else
-> > +            slist_cross_notify = g_slist_prepend (slist_cross_notify, NULL);
-> > +          if (slist_cross_notify->data)
-> > +            gtk_widget_event (slist_cross_notify->data, event);
-> > +          break;
-> > +
-> > +        case GDK_LEAVE_NOTIFY:
-> > +          if (slist_cross_notify->data)
-> > +            gtk_widget_event (slist_cross_notify->data, event);
-> > +          slist = slist_cross_notify;
-> > +          slist_cross_notify = slist->next;
-> > +          g_slist_free_1 (slist);
-> 
-> Hmmm, this does have the disadvantage that events can be sent
-> to a grab window after it has lost its grab, and in fact,
-not events (in the sense of *any*) but leave_notify.
-
-> after it has been destroyed! I'll have to think about this 
-
-yep, i just figured it also segfaults if we get leave_notify for
-sub windows. it was late last night, and i just tested an idea ;)
-
-> some more ... I'm not sure this is the right approach.
-> 
-> > for now the patch just disables the compression of leave/notify
-> > events and can therefore create a stack.
-> 
-> Why should that be necessary? An enter/leave pair on the same
-> window shouldn't affect a stack, if you want one.
-
-this is correct, but the old compression code just removed one event
-and would the other appear "spurious", and it didn't take subwindows
-into account which has the same effect.
-
-> > regarding the compression, owen/jay could you take a look at it?
-> > it seems to me next_event needs to be freed as well.
-> > in general i would just say it should look similar to:
-> > 
-> > if ((event->type == GDK_ENTER_NOTIFY) &&
-> >     (next_event->type == GDK_ENTER_NOTIFY) &&
-> >     (next_event->any.window == event->any.window))
-> > {
-> >   [throw away *both* events]
-> > }
-> > 
-> > or am wrong here.. ?
-> 
-> I think your right. In fact, the lines there:
-> 
-> 	    tmp_list = current_events;
-> 	    current_events = g_list_remove_link (current_events, tmp_list);
-> 	    g_list_free_1 (tmp_list);
-> 
-> Look useless and wrong since the event hasn't even been added
-> to current_events yet.
-
-agreed.
-
-now, i just rewrote the code with widget referencing and subwindows in mind
-and still got it to crash, because enterin/leaving is more complex than one
-would think at the first glance:
-
-(this is the grab example from my last mail)
-
-[window creation]
-configure notify:       window: 58720262  x,y: 826 23  w,h: 200 200
-reparent notify:        window: 58720262
-map notify:             window: 58720262
-expose:         window: 58720262  0  x,y: 0 0  w,h: 200 200
-map notify:             window: 58720279
-configure notify:       window: 58720279  x,y: 0 0  w,h: 200 200
-expose:         window: 58720279  0  x,y: 0 0  w,h: 200 200
-
-[move the pointer in]
-focus in:               window: 58720262
-client message: window: 58720262
-client message: window: 58720262
-
-[enter the main window, which is totaly obscured
-by the buttons window, therefore we only get it's enter event
-including the subwindow]
-enter notify:           window: 58720262  detail: 4 subwin: 58720279
-enter notify:           window: 58720279  detail: 3 subwin: 0
-client message: window: 58720262
-client message: window: 58720262
-
-[press button 1]
-button press[0]:                window: 58720279  x,y: 102 148  button: 1
-
-[move pointer out of the window]
-leave notify:           window: 58720279  detail: 3 subwin: 0
-leave notify:           window: 58720262  detail: 4 subwin: 58720279
-
-[release the button]
-button release[0]:      window: 58720279  x,y: 99 223  button: 1
-
-[now we get "spurious" leave events, because of the button release,
-and i had a nice stack-uderflow ;)]
-leave notify:           window: 58720279  detail: 0 subwin: 0
-leave notify:           window: 58720262  detail: 1 subwin: 58720279
-
-
-hm, with this in mind, i'm ready to drop the stack approach, and
-spend another widget flag GTK_IS_ENTERED or so, which determines
-wether to send a leave event (if the widget is insensitive) or not...
-
-
-> 
->                                         Owen
-> 
-
----
-ciaoTJ
-
 From timj@gimp.org Sat Jan 24 19:15:22 1998
 Date: Sat, 24 Jan 1998 18:25:10 +0100 (CET)
 From: Tim Janik <timj@gimp.org>

TODO

@@ -69,6 +69,17 @@ DND
   gtk_widget layer that makes it easier... Also, adding support for drop
   zones might be nice.
     -- Elliot
+  This one is reproducabel for me:
+  testgtk --sync
+  popup colorselection
+  drag/drop works
+  start up preview color
+  drag works but not dropping
+  end preview color
+  drag/drop works
+  start up prewiev color
+  segfault in malloc
+  -timj
 
 OTHER
 -----

gtk/gtkmain.c

@@ -328,8 +328,8 @@ gtk_main_iteration_do (gboolean blocking)
 	  }
 
       /* Push the event onto a stack of current events for
-       * gdk_current_event_get */
+       * gtk_current_event_get().
-
+       */
       current_events = g_list_prepend (current_events, event);
       
       /* Find the widget which got the event. We store the widget