[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Unlinking a notebook page
- From: Dr.Peter Rottengatter <peter rottengatter de>
- To: gtk-app-devel-list gnome org
- Subject: Re: Unlinking a notebook page
- Date: Sun, 7 Apr 2002 23:57:23 +0200
On Tue, 26 Mar 2002 21:45:12 +0100, Dr. Peter Rottengatter <peter@arisia.rottengatter.de> wrote:
> > > Now I've mentioned gtk_notebook_remove_page above, which I looked at a bit
> > > closer. I found that saying it discards the removed page is not quite right.
> > > In fact I can obtain a pointer to the page-top-level widget (the one that's
> > > been inserted into the notebook using gtk_notebook_append_page), then remove
> > > that page, and I can still play with the page sub-tree.
> >
> > ? discarded = deleted = deallocated ?
> > A widget will not be deleted until its reference count is zero. If you
> > increment the reference count on a widget then when you remove it from
> > some container (like a packing box or notebook) then the widget will not
> > be deleted.
>
> Good point. I did not increase (or decrease, for that matter) the reference
> count at all. However, the code for creating the window with all it's contents
> (packing boxes, notebook, labels etc.) is written by Glade, so I should check
> if that increments the ref count.
Glade does some pretty interesting stuff: On every single widget that's created
by it (i.e. the source code created by Glade),
gtk_widget_ref (mt_flag_acp);
gtk_object_set_data_full (GTK_OBJECT (magic), "mt_flag_acp", mt_flag_acp,
(GtkDestroyNotify) gtk_widget_unref);
is called. Now, this puzzles me. Doesn't this just increase the ref level during
normal operation by one, while still fully destroying it upon gtk_widget_destroy
(due to the extra ref count decrease by the callback) ? What is it good for ?
> So that would explain why I could still play with the notebook page sub-tree
> (a GtkVBox with children BTW) even though gtk_notebook_remove_page was called
> for that page.
It certainly neatly explains why I could play with the notebook pages even though
I had called gtk_notebook_page_remove previously.
> What it does not explain is why problems popped up when I
> gtk_widget_destroyed the window with the notebook from which the page was
> removed.
... is still an unresolved mystery.
> I would think the removal action should sever all the links, i.e.
> playing with the (now unlinked) page sub-tree and destruction of the (former)
> parent notebook widget along with the widget tree to which it belongs should
> be altogether independent ?!
Shouldn't it ?
Another question: What should happen, if I gtk_widget_destroy a window with a
sub-tree of other widgets that are shown in the window, and one widget further
down in the sub-tree has a reference count of 2 or larger ?
Cheers Peter
--
---------------------------------------------------------------------
Dr. Peter Rottengatter peter@rottengatter.de
http://www.rottengatter.de
---------------------------------------------------------------------
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]