Re: Nautilus toolbars and Bonobo

[Nat Friedman <nat helixcode com>]

John Sullivan <sullivan@eazel.com> writes:

> > But honestly, components cannot reliably use Bonobo toolbars until we
> > have a new GtkToolbar.  So I see there being basically two options:
> > fix GtkToolbar, or forget about Bonobo toolbars.
> 
> I hadn't realized the situation was this dire until today. Now I realize.

The main issue is that you can't remove items from the toolbars; the
space the items were taking up stays blank.  The toolbar has to be
fixed to relayout every time its child count changes.  This really
can't be that hard.

> > Of course, I'm not really sure why a component should be able to
> > override the 'back' item on the main toolbar in the first place.  This
> > doesn't sound like a great idea to me, but I don't know the grand
> > designs for Nautilus.
> 
> The theory was, if you want to be able to have components merge into the
> toolbar, then all the items in it need to be created the Bonobo way. So if
> we want it to be possible for a component to add an item to the end of the
> main toolbar, then it is automatically also possible for a component to be
> able to override the 'back' item or any other item. Not that we expect that
> particular thing to happen.

Well, that's not necessarily true.  There's a nasty trick you can do...

Basically, create the Up/Back/Forward GtkToolbar, wrap it in a Bonobo
control, and then stuff that wholesale into the Bonobo toolbar.  That
way other toolbar buttons can be appended.  The limitations are:

    . You can't override individual elements in the Up/Back/Forward
      GtkToolbar.

    . You can't insert items into the middle of the U/B/F toolbar.

    . There might be a couple of pixels lost due to GtkToolbar
      padding.

This is what Ettore used to be doing in GtkHTML.

Nat