Re: EggToolbar vs. GtkToolbar compatibility

[Owen Taylor <otaylor redhat com>]

On Sat, 2003-04-05 at 13:42, Soeren Sandmann wrote:
> 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.

My opinion on whether it is acceptable is basically: it is acceptable
if it doesn't actually break application code. I don't think
we've _documented_ anywhere that the above should work.

We can make:

 gtk_container_remove (toolbar, w);

work when w is a grandchild of the toolbar, and I think that's the
main place where we'd be likely to run into trouble leaving aside
the possibility of people doing really horrid hacks that will most
likely break anyways.

It might make sense to try to drop in the EggToolbar code for
GtkToolbar and just go through all the GNOME apps and various
other GTK+-2.x apps (GIMP, gnumeric) and see what happens.

> 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

I realy, really, would like to avoid this. Having three list widgets,
two file selectors, 2 menu item handling systems, etc, is plenty
of confusion already.

And I can't imagine a decent alternate name.


> 	- Make EggToolbar compatible.

If this can be done in a strict sense, without too much internal
horror in the code, it's certainly better than risking
incompatibilities.

> 	  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

This wouldn't worry me too much ... ::get_child_type() is not
used extensively.

> 		- 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?

We already say that the two API's are exclusive. I forget the 
details, but I definitely discussed this with Anders at some point.

I don't agree that just adding a new widget would be better ... having
the right widget have the right name is quite important for the 
ease of use of the API.

Regards,
                                      Owen