mirror of
https://gitlab.gnome.org/GNOME/gtk.git
synced 2024-12-26 13:41:07 +00:00
added BUGS. -timj
added BUGS. -timj
This commit is contained in:
Tim Janik
parent
36b2a2ebcd
commit
6365ebc9ea
182
BUGS
Normal file
182
BUGS
Normal file
@ -0,0 +1,182 @@
|
|||||||
|
|
||||||
|
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
|
SRC_SUBDIRS = glib gdk gtk
|
||||||
SUBDIRS = $(SRC_SUBDIRS) docs
|
SUBDIRS = $(SRC_SUBDIRS) docs
|
||||||
|
|
||||||
EXTRA_DIST = gtk+.prj makecopyright TODO REFCOUNTING
|
EXTRA_DIST = gtk+.prj makecopyright TODO REFCOUNTING BUGS
|
||||||
|
|
||||||
.PHONY: files populate checkin release
|
.PHONY: files populate checkin release
|
||||||
|
|
||||||
|
|||||||
31
TODO
31
TODO
@ -15,6 +15,34 @@ BUGS
|
|||||||
* Vertical scrollbar: the expose event looks hosed and is causing
|
* Vertical scrollbar: the expose event looks hosed and is causing
|
||||||
quite a bit of flickering
|
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
|
NEW FEATURES
|
||||||
------------
|
------------
|
||||||
* gdk_expose_compress: ala-Xt, this would really help for opaque moves and
|
* 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.
|
-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?
|
-More dialogs? Print, font, etc?
|
||||||
|
|
||||||
-Multiple document interface (MDI)?
|
-Multiple document interface (MDI)?
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user