Toolbar control frames.

[Nat Friedman <nat nat org>]

Hey Miguel,

    So I implemented most of the UIHandler changes we talked about on
the phone, namely:

        1. Dumping all of the existing toolbar code.

        2. Allowing embedded components to pass entire toolbars as
           Bonobo Controls.

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.

    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.

    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.

    But the main problem is that the Control/ControlFrame
implementations aren't really done.  So I need to fill them out a bit
in order to continue, but I wanted to check with you first.  The
missing pieces, enumerated with the primary colors, are:

        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?

So that's the long-and-short of it.  Will commit, pending your
approval.

Nat