Re: src/toolbar-factory.c:320

["M . Thielker" <balsa t-data com>]

Hi,

On 2001.07.20 19:41 Pawel Salek wrote:
> Also, it is a bad implementation to destroy GtkToolbarChildren by hand.
> Destroying GtkToolbar object would have the same effect and would not
> rely on the GtkToolbar implementation details. The GtkTolbar should be
> treated as opaque object.

Doing that, customizable toolbars wouldn't be possible at all. If I save
just the toolbar handle, ther's not much I can do with it. If I destroy the
toolbar, the dock on the parent window remains. When a new toolbar is
created, the window will create a new dock. After a few changes, this
becomes very unsightly.
There is no way to (a) cleanly detach a toolbar from a window and (b) to
remove all children of a toolbar by api calls. I was stuck with either
removing the empty dock from the parent window, that would rely on the
children of the parent and access internals of the parent, or to leave the
toolbar intact but remove it's children. Just destroying the children will
not properly remove them from the toolbar's management structures, this is a
gtk bug, I think. The toolbar should have a destroy callback on each of it's
children.

I made the assumption that the window is a more complex construct, more
likely to change in future versions, while the toolbar is a functional unit
which will likely not change too much. So I decided to rely on toolbar
internals rather than window internals.
Without doing one of these two things, doing customizable toolbars is not
possible with the GtkToolbar class, I would have had to write a new toolbar
from scratch.

Melanie