Commit 6365ebc9 authored by Tim Janik's avatar Tim Janik
Browse files

added BUGS. -timj

added BUGS.
-timj
parent 36b2a2eb
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>
To: Peter Mattis <petm@xcf.berkeley.edu>
Cc: Gtk+ Devils <gtkdev@gimp.org>
Subject: widget destruction while in call
hi peter and gtk+ devils ;)
i've got the following problem, when double clicking on a list item
it's window should be destroyed, because the selection is made.
now this doesn't work 'cause the program is aborted with a
BadWindow error (from X).
this happens because the function that is connected to the lists
button_press_event calls gtk_widget_destroy () on the main window.
then the widget destruction is propagated through the tree until
the list widget should be destroyed. but since the list widget is
still GTK_IN_CALL (from the button_press_event) it isn't destroyed
but only flagged as GTK_NEED_DESTROY. at this point the propagation
stops, and nothing happends to the list widgets children.
after the return of the button_press_event handler, the clicked
list item is now selected/unselected (depends on the previous state).
it therefore updates its GdkWindow (XWindow) by setting the new
backgroundcolor (selected->blue/unselected->white). since it's
parent XWindows are destroyed already the window which the list item
wants to draw on is also destroyed. at this point the BadWindow error
occours cause the XWindow handle has become invalid (the application
already received a destroy notify).
now, solutions might be:
1) check for private->destroyed on *all* gdk call as it's done
it a lot of places already, or
2) propagate a widget unrealize signal through the tree before
destroying a widget, or
3) propagate GTK_NEED_DESTROY down the tree (not only flag the
list container), this would require gtk_object_destroy() to
return wether the object got actually destroyed or flagged
only. then prohibit gdk operations on widgets flagged as
GTK_NEED_DESTROY.
i'm not sure what the best solution might be, but i tend to favour
1) or 3).
---
ciaoTJ
......@@ -3,7 +3,7 @@
SRC_SUBDIRS = glib gdk gtk
SUBDIRS = $(SRC_SUBDIRS) docs
EXTRA_DIST = gtk+.prj makecopyright TODO REFCOUNTING
EXTRA_DIST = gtk+.prj makecopyright TODO REFCOUNTING BUGS
.PHONY: files populate checkin release
......
......@@ -15,6 +15,34 @@ BUGS
* Vertical scrollbar: the expose event looks hosed and is causing
quite a bit of flickering
* Make sure a widget added to a list is a list item and a widget added
to a menu is a menu item, etc. GTK_BASIC was a first attempt at this,
but it fails with subsequent container_add()s. maybe have another
GTK_PARENT_BASIC (similar to GTK_PARENT_SENSITIVE) flag, to prevent
tree iterations upon every container addition.
* Make gtk_menu_item_set_submenu() and gtk_option_menu_set_menu() fit into
the normal tree manner (e.g. make propagation possible).
* GtkOptionMenu needs to reference its curent GtkMenuItem.
* Right after creation of an option menu, the first selected menu item is
placed too low (is this still true?).
* GtkMenu needs to properly unref() accelerator tables upon destroy.
* Display of GtkToggleButton is messed up if GtkContainer::container_width
is greate than 0. GtkCheckButton and GtkRadioButton are only messed up
if draw_indicator is FALSE.
* Using gtk_container_add() on an option menu to add a label works, but then
gtk_option_menu_button_press() segfaults. This is supposed to fail while
adding due to a g_return_if_fail (GTK_IS_MENU_ITEM (child));
* Look also at ./BUGS (i added it, because it describes some bugs in
a more specific way -timj).
NEW FEATURES
------------
* gdk_expose_compress: ala-Xt, this would really help for opaque moves and
......@@ -56,9 +84,6 @@ Other stuff todo, as of yet not categorized into the above:
-Widget redrawing when the window resizes sometimes messes up.
-Make sure a widget added to a list is a list item and a widget added
to a menu is a menu item, etc...
-More dialogs? Print, font, etc?
-Multiple document interface (MDI)?
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment