Re: GtkImageMenutItem

[Tim Janik <timj gtk org>]

On 14 Feb 2001, Havoc Pennington wrote:

> Tim Janik <timj gtk org> writes:
> > here are a couple comments regarding the newly added
> > image menuitem. first, i think the name is a bit odd
> > as that menu item can hold any kind of extra widget,
> > not only an image.
> 
> Yes, but GtkWidgetMenuItem is blatantly a bad name (overlaps with
> GtkWidget namespace if nothing else), and it will always contain an
> image in practice. I'm open to better ideas.

> The comment is correct, though perhaps confusing. The point of the
> comment is that the GtkContainer default implementation of destroy
> (which we chain to) destroys all non-internal widgets. So we don't
> need to do anything in destroy. But if you changed the image widget to
> be internal, you would need to destroy it in destroy. I thought people
> might suggest this change, so I put the comment as a reminder.

just note that, if it were internal you'd not be obligued to destroy
it in ::destroy, e.g. a widget may validly create a composite child
in _init and get rid of it only in finalize (of cousre implementations
that can deal with such composite children not being present are alwways
better and then you'd destroy the child in ::destroy as well).

> > this is _way_ hackish. first, we don't overload public API in
> > derived classes (here, gtk_container_remove), 
> 
> I'm not overloading it, I'm overriding it, look again. It does appear
> I left off the "static," oops. Anyway, gtk_container_remove() should
> work on the image widget, that is the purpose of this override.

right, you missed the "static" which makes it appear as public API.

> > second, it breaks
> > pair-ness of gtk_container_add/gtk_container_remove.
> > get rid of this and use just gtk_image_menu_item_set_image().
> 
> I don't understand what you mean by "breaks pair-ness".

about the pair-ness, if you want container_remove to work on it,
container_add should as well.
also, the image should be exported through a GTK_TYPE_WIDGET
property, so builders can deal with the extra slot.

> 
> Havoc
> 

---
ciaoTJ