Re: gettext domain(s) and Bonobo

[Miguel de Icaza <miguel gnu org>]

Hello Michael,

> 	  My preferred solution is this ( for toolbars at least ).
> 
> 	  a) Create a public GnomeToolbarItem

Could you explain to me what a GnomeToolbarItem is?

I agree, I have also the feeling that rolling our own toolbars for
Bonobo is better than dealing with GtkToolbars, as those ones lack
support for dynamic items.

> 	  d) Let components embed their toolbars via controls ( which would
> contain a few of the standard GnomeToolbarItems BTW ).

I thought this was what we did?  At least entire toolbars were
supposed to be transfered in this way.

> 	  This solves a scad of dynamism problems since the container
> hierarchy can cope well with sub-widget removal. I suppose something
> similar is neccessary for menus, but I get far less convinced there. This
> would also kill many thousands of lines of code from the ui-handler I
> hope.

Menus are harder to handle.  We do not want to create Bonobo controls
for every menu item (Although providing this optionally might not be a
bad idea at all).

> 	  Also, I am rather appalled by the GnomeUIInfo structures that
> float everywhere in the gnome-app stuff. Perhaps I horribly misunderstand
> these, but it seems these are bad news for me; I can understand the need (
> perhaps ) for structure initialization of menu trees for code simplicity,
> but why are the internals not implemented with standard widget / container
> GtkObjects ?

Historial reasons.  We were young, we were beginning, and writing a
new GtkObject for this was a big deal back then.  These days we create
GtkObjects left and right.

Miguel.