Re: Toolbar control frames.

[Nat Friedman <nat nat org>]

Miguel de Icaza writes:
 > 
 > > 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.
 > 
 > Is there any chance we can have mixed support for this?

Yes.. it's more complicated but I can do that.

 > >     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.
 > 
 > This seems like the best approach, to minimize the code the
 > component-implementor needs to write.  Can we get this?

    No, it's not a code-minimization issue.  My code handles all of
the control-wrapping for the component author.  They just call

        gnome_ui_handler_add_toolbar (uih, "toolbar_name",
                                      toolbar_widget);

and it does the rest.

 > If you need to move functionality from the view to the control, please
 > feel free to do so.  The less code the programmer writes, the
 > better.

    Ok.  It will break the API, though, since the view functions will
no longer be available.


 > That is fine.  We can fix them and during a transition phase, we can
 > provide aliases.

    Word up.


 > > 	  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?
 > 
 > Yes, you are correct.  Now, how do we make Views behave correctly if
 > they derive from Controls?

    We override the _new() method for views, and get the normal Bonobo 
size negotiation semantics.

 > Your ideas are just perfect, so could you do the moving of stuff from
 > view->control?  I can do the aliases and fixing of code if you need me
 > to.

Ok.  On the case.

Nat