Menus and refcounting
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list redhat com
- Subject: Menus and refcounting
- Date: 01 Sep 1998 10:07:44 -0400
I just noticed that my recent menu changes resulted
in refcounting for menus being a bit screwy.
The way it used to be:
Menus were created floating with a refcount of 1. If/when
a menu was attached to something with gtk_menu_attach_to_widget.
(E.g., this is called by gtk_menu_item_set_submenu), they
were sunk. By convention when the attach_widget was destroyed,
it destroyed the men. If the menu was detached, it was
unref'ed.
The way it is now.
Menus, when created immediately add themselves at once to a parent
that they create. (Menus are no longer toplevel
widgets) This means that they get a non-floating refcount
of 1. When a menu is attached to something, the refcount
is incremented to 2. If the attach_widget is destroyed,
then it destroys the menu, the toplevel is destroyed,
both refcounts are released, and everything is fine. If
the menu is removed from the attach_widget, the refcount
will remain at 1, and the menu potentially leaks.
I think the "right" thing to do here is to try and restore
the old behavior, since that is pretty much constistant
with how other widgets work.
So, what I plan to do now are hacks like:
gboolean was_floating = GTK_WIDGET_FLOATING (menu);
gtk_container_add (GTK_CONTAINER (menu->toplevel), GTK_WIDGET (menu));
if (was_floating)
GTK_WIDGET_SET_FLAGS (GTK_WIDGET (menu), FLOATING);
gtk_widget_unref (menu);
[...]
gtk_widget_ref (menu);
gtk_container_remove (GTK_CONTAINER (menu->toplevel), widget);
That is hiding the toplevel=>menu refcount, but recreating
it when needed. This is ugly, but shouldn't be apparent
to users. I'd appreciate better ideas, however.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]