Re: Looking at EggToolbar

[Owen Taylor <otaylor redhat com>]

On Sat, 2003-04-05 at 14:01, Soeren Sandmann wrote:
> Soeren Sandmann <sandmann daimi au dk> writes:
> 
> > > what I might suggest instead is functions on EggToolItem
> > > that look at the toolbar and get these configuration options:
> > > 
> > >  egg_tool_item_get_orientation()
> > 
> > What is this going to return when the item is not inside a toolbar?
> > Are you required to pass in a toolbar?
> 
> I forgot my own suggestion here: Have gtk_toolbar_get_icon_size()
> etc. and an EggToolItem::toolbar_reconfigured signal.

This is certainly a possibility. The main difficulty I see there
is that you then are in an "indeterminate" icon size state in
the constructor, so you have do something special in ::parent-set,
rather than just being able to construct according to the current
values and handle ::toolbar-reconfigured.

(I suppose a way of handling this is to say that 
::toolbar-reconfigured will always be emitted when the item 
is added to a toolbar, but that still, in my opinion, leaves
a rather ugly indeterminite initial state that has to be 
coded around.)

It's also awkward to have to duplicate code to get the toolbar
for a toolitem in multiple places... you'd need at least
egg_tool_item_get_toolbar().

> Another thing I forgot:
> 
> What are the precise semantics of 
> 
>         GtkWidget *EggToolItem::create_menu_proxy() ?
> 
> This call is supposed to return a menu item, and the caller must make
> sure the item is destroyed. But who is responsible for keeping the
> item up-to-date with respect to label and checked-ness and such? If
> the tool item is responsible, then tool items need to keep a list of
> weak references to all items ever created around and keep all those
> menu items up-to-date.
> 
> I don't necessarily think this is a problem, but it may come as a
> surprise. The code to maintain this list can be kept in the base class
> and shared between tool item implementations.
> 
> Note that keeping one menu item around and handing references to that
> out is not good enough, because this one menu item could then be added
> to more than one menu.

Why would this happen? Can we just say by fiat that there will only
ever be one proxy menu item for a tool item?

One way of making this explicit is to have:

 void egg_tool_item_set_menu_proxy (item, proxy);
 GtkWidget *egg_tool_item_get_menu_proxy (item, proxy);

and to get rid of the return value from the ::create_menu_proxy
signal. (Return values from signals are always a bit awkward
and confusing in any case.)

Regards,
                                       Owen