Re: Looking at EggToolbar

[Owen Taylor <otaylor redhat com>]

On Sun, 2003-04-20 at 16:18, Soeren Sandmann wrote:
> Owen Taylor <otaylor redhat com> writes:
> 
> > 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.)
> 
> I don't see how your suggestion avoids doing something special in
> ::parent-set. When a ToolItem has just been created, its
> get_icons_size() will just return the default (SMALL_TOOLBAR,
> say). Based on that the toolitem will create a SMALL_TOOLBAR
> icon. When the item is added to a toolbar that has icon size
> LARGE_TOOLBAR, the item will have to do something special.
> 
> So I actually don't really see how the two possibilities are different
> in this respect. The reason I'd like to avoid
> tool_item_get_icon_size() is that I think the icon size conceptually
> belongs on the toolbar, which needs this accessor anyway.

My point is not that *nothing* will have to be done in ::parent-set,
but that individual items should only have to worry about a single
signal, and that the handling of ::parent-set can be done in
generic code.

> > 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().
> 
> I would only access the toolbar out of the two signals
> toolbar_reconfigured and parent_set. In both cases the toolbar is
> easily available.

I really don't care that much. I don't think people will be writing
lots of custom toolbar items.

But we *certainly* should have egg_tool_item_get_toolbar() - writing
assuming widget->parent a EggToolbar, is bad practice and non-robust,
and checking all over the place that the parent is an EggToolbar is a
mess.

Regards,
                                          Owen