Re: Unlinking a notebook page, was: gtk_widget_unparent

["Norman Black" <stonybrk ix netcom com>]

> Ok, found out there is no such thing as gtk_container_remove.
According to
> docs, add/removal functions are all implemented by the inheriting
classes.

I actually call gtk_container_remove in my code, so it must exist. I use
it when removing something from a packing box (hbox or vbox). The
packing boxes do not have a remove API call so you must use the
"inherited method" which is gtk_container_remove.

> 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. All container widget increment the reference count when a
widget is added to them, and reverse that when removed. When I want to
move a widget from one location to another I use gtk_widget_ref on said
widget so when it is removed it stays alive. After I put it into its new
location I use a gtk_widget_unref. Sometimes I just keep an "extra"
reference count on a widget and control removal to a time and place of
my choosing.

Am I on track or off, with what you a trying to do?

Best Regards,
Norman Black
Stony Brook Software

----- Original Message -----
From: "Dr.Peter Rottengatter" <peter rottengatter de>
To: <gtk-app-devel-list gnome org>
Sent: Saturday, March 23, 2002 3:02 AM
Subject: Unlinking a notebook page, was: gtk_widget_unparent


> On Fri, 22 Mar 2002 16:21:28 +0100, Dr. Peter Rottengatter
<peter rottengatter de> wrote:
> > > You should probably use gtk_container_remove to remove a widget
from a
> > > container widget, unless the contain widget has a specific removal
API
> > > call. For example the notebook widget has its own API for removing
a
> > > page. Things like the packing boxes do not.
> >
> > I'll check gtk_container_remove, thinks for the hint, but from the
> > wording of the function name I suspect it does pretty much the same
as
> > gtk_notebook_remove_page, i.e. removing and *discarding* the
sub-tree,
> > leaving the notebook with one page less behind. I want it exactly
the
> > other way round.
>
> Ok, found out there is no such thing as gtk_container_remove.
According to
> docs, add/removal functions are all implemented by the inheriting
classes.
> 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. I tried using
this
> for my problem, i.e. notebook_append'ing it into another notebook.
This works
> perfectly, even with lots of further gtk object creation and
destruction
> going on in the program after that. Hmm, should say "almost
perfectly", though,
> as there is still one thing unresolved: gtk_widget_destruction of the
notebook
> from which the page is removed immediately creates problems with
handling the
> removed page. So this means, gtk_notebook_remove_page doesn't even
sever all
> the links to and from the page.
>
> Seems I really have to dig into the GTK source code to find out which
pieces
> of the docs are right, and what gtk_notebook_remove_page really does.
>
>
> Cheers  Peter
>
> PS.: Why is it that it takes several days until postings to the
mailing list
>       actually appear in the list ? What I cited above came from my
outbox,
>       rather than the echo from the mailing list, even though the
original
>       posting was sent some 20 hours ago.
> --
> ---------------------------------------------------------------------
>       Dr. Peter Rottengatter       peter rottengatter de
>                                    http://www.rottengatter.de
> ---------------------------------------------------------------------
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list