Re: Toolbar control frames.

[Federico Mena Quintero <federico redhat com>]

>  One deficiency with this setup, as we discussed, is that you can no
>  longer merge individual toolbar items into alien toolbars.  I thought
>  I had seen this happen with MS OLE, and the problem became more
>  pronounced to me as I deleted the code I wrote to handle this, but I
>  will take it on faith that you are right on this issue, and that users
>  won't need this functionality.  If they do, my old code can be
>  reinstated and fixed-up.

I have a similar problem in the Eye of Gnome.  The toolbar may change
to reflect the contents of a window, which can switch between
image/collection/empty modes.  In all modes the toolbar at least has
"open" and "close" buttons.  However, toolbars for windows in the
image mode have the zoom buttons in them.  Toolbars for image
collection windows will have stuff like "delete", "slide show", etc.

So I have some base items that never change, and stuff that needs to
change.  I can mostly pull it off by inserting contiguous ranges of
toolbar items and removing them as appropriate.  One important caveat
is that you cannot remove a space from a GtkToolbar.  This needs to be
addressed, and would be a worthy addition to the Gtk 1.4 API (or maybe
we just need a better toolbar widget).

As far as Bonobo is concerned, it may be simpler to have an embedded
component return a complete toolbar, and have the toplevel container
create a new dock item for that toolbar.  Then it can slap that dock
item onto the "important" dock band, so your main dock band would be
composed of several dock items, one for each component that needs
toolbar stuff in there.

>      But basically what we have now (for better or for worse) is a way
>  of embedding a generic widget into the top-level app's GnomeDock using
>  the UIHandler.

Just have that widget be wrapped with a Control, and insert the
parent-side widget into the toolbar.

>      Another issue is that a component has to recreate all of the
>  controls every time it gets focus.  Not sure if this is going to be a
>  performance problem; if it is, I can implement hide/show methods which
>  toggle the visibility of the GnomeDock into which the toolbars get
>  embedded.

I would not worry about performance until we test this.  Creating
widgets is fairly fast; the only overhead will be the IPC and the time
to create the Control wrappers.

>          Red.  Currently it is a pain to embed Controls in your
>                application, since you still have to do all of the
>                set_window() magic yourself.  We make this easy with
>                subdocument embedding by providing a GnomeWrapper widget
>                in GnomeViewFrame and by adding some nice sugar to
>                GnomeClientSite.  So I think we're going to want to use
>                an always-active Wrapper in GnomeControlFrame and add
>                the same sugar there as well (namely, connecting to the
>                realize signal on the wrapper and calling set_window()
>                on the embedded control).
>  
>                I've gone ahead and implemented this, but wanted to make 
>                sure it was cool with you before commiting.
>  
>          Green.  GnomeView and GnomeViewFrame should probably derive
>                  from GnomeControl and GnomeControlFrame a bit more
>                  directly.  This is basically a no-brainer, but it does 
>                  involve moving some methods to the ControlFrame and
>                  Control, out of the ViewFrame and View.  Which will
>                  probably break some people's code.
>  
>          Blue.  Now, for GnomeViews, we did our own semi-special
>                 size-negotiation semantics.  But for Controls, I think
>                 we want to just directly proxy the Gtk signals.  That's
>                 what I ended up doing for the toolbars, anyways, and I
>                 got the feeling a lot of people would end up doing the
>                 same.  Because, in reality, most controls will just be
>                 CORBA wrappers for widgets or sets of widgets.
>                 Thoughts?

I don't think this is the best enumeration, as it is unfriendly to
color-blind people.

I think the Control interface needs to make things look as much as
widgets as possible, so that they blend in nicely with the surrounding
widgets.  You need to proxy stuff like sensitivity --- you can assume
that the embedded children are widgets, so you may want to desensitize
them for the proper visual appearance instead of overlaying a
Wrapper-like stipple on them.  You also need to handle focusing with
respect to keyboard navigation.  This is a bit tricky, as you do *not*
want recursive focusing like in the current GtkNotebook, since it is
fantastically confusing; you want position-based focusing instead.

  Federico