Re: Toolbar control frames.

[Miguel de Icaza <miguel gnu org>]

> 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?

>     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?

> 	  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.

The control interface was actually never tested on real life.  Some
people already pointed this out, but I was busy doing something else,
so I got side tracked.

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.

> 	  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.

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

> 	  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?

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.

Best wishes,
Miguel