[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Unlinking a notebook page



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]