EggToolbar vs. GtkToolbar compatibility

[Soeren Sandmann <sandmann daimi au dk>]

What level of compatibility are we guaranteeing for EggToolbar?
Currently, we are not really compatible, because if you use the
deprecated API,

	egg_toolbar_append_widget(),

say, the appended widget will end up being a child of a newly created
EggToolItem. This means that perfectly legal code:

	GtkWidget *w = gtk_button_new();

	gtk_toolbar_append_widget (toolbar. w, NULL, NULL);

	assert (w->parent == toolbar);

will break. I don't think this is acceptable.


Possibilities:

	- Make EggToolbar a new widget that is simply incompatible
          with GtkToolbar, and leave GtkToolbar in gtk+.
		
		advantage: a relative simple solution
		disadvantage: we have to think of a new name

	- Make EggToolbar compatible.

	  This means widgets that are added to the toolbar using the
	  old API must be proper children of the toolbar. They can't
	  be wrapped in EggToolItems. Some consequences:

		- some reorganization of EggToolbar is necessary.

		- the toolbar viewed as a container must contain
		  GtkWidgets, not EggToolItems. That is
		  container::get_child_type() must return
		  GTK_TYPE_WIDGET

		- it is a litlle unclear to me what it will mean to make
		  homogeneous/pack end/expand child properties 

                - gtkcontainer::add() and ::remove() must be able to
                  handle both GtkWidgets and EggToolItems. 

                - gtkcontainer::forall() will traverse both
                  EggToolItems and GtkWidgets.
	  
It may be possible to get around some of this by making the old and
the new API mutually exclusive, so that if you use the old API, you
can't use the new, and if you use the new API, you can't use the
old. But if we do that, isn't it better to just add a new widget?


Søren