From 1ff162c4452555fa04da224a14865405f5d1963d Mon Sep 17 00:00:00 2001 From: Tim Janik Date: Fri, 30 Jan 1998 01:34:19 +0000 Subject: [PATCH] some bugs worked out. comment cleanups -timj --- BUGS | 133 -------------------------------------------------- TODO | 11 +++++ gtk/gtkmain.c | 6 +-- 3 files changed, 14 insertions(+), 136 deletions(-) diff --git a/BUGS b/BUGS index cf82178ba6..fcec7cbf4d 100644 --- a/BUGS +++ b/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 -To: Owen Taylor -Cc: Gtk+ Devils -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 diff --git a/TODO b/TODO index 245ca70eaf..aa5e918109 100644 --- a/TODO +++ b/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 ----- diff --git a/gtk/gtkmain.c b/gtk/gtkmain.c index 1a4182816a..07ec23b51d 100644 --- a/gtk/gtkmain.c +++ b/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 @@ -876,7 +876,7 @@ GdkEvent * gtk_get_current_event () { if (current_events) - return gdk_event_copy ((GdkEvent *)current_events->data); + return gdk_event_copy ((GdkEvent *) current_events->data); else return NULL; }