Re: scripting with bonobo

[Michael Meeks <michael helixcode com>]

Hello James,

On Mon, 26 Jun 2000, James Vandenberg wrote:
> It is solved o&o agian because each application is developed 
> independently. Their is no major incentive to make the scripting
> interface common. (That I know of, in my limited experience.)

	There is in the GNOME project; we want nice, sweet integration
between components, at the moment I havn't had time to get to scripting,
furthermore there are a number of 'interesting' issues that I need to
consider such as: security, DSI/DII or idl parsing or a new 'type library'
concept, object namespaces etc.

> It would be even better if there was a Bonobo::Data module, with some 
> general purpose data structures. While we're at it, how about we make 
> them the primary means of inter object communication.

 [ ... huge block of text ... ]

> between it and it's view. Calling functions would be easy too:
> 
> interface ScriptEngine {
> 
> Data::Script compile (in string script);
> Data::Unknown run (in Data::Script program, in string function, 
> Data::List parameters);
> 
> };
>  	
> I think Bonobo should move in this direction. 

	James, my friend. If you want bonobo to go in this direction, and
indeed it sounds like a most excellent direction to go in then you must:

	a) Produce a sample implementation using Bonobo
	b) Produce a small demo app to show everone how amazing it is
	c) Post it to the list
	d) Sit back and watch the plaudits roll in.

	There may be idle manpower lurking here willing to help you, but
concrete code bears more weight than 10 tonns of E-mail.

> I don't think it will,  because, 
> as far as I can see, It's trying to be GNU OLE. While OLE has it's good 
> points, It has some points, that while not particularly dangerous in the 
> Windows world, are not good in a free software world. 

	It would seem to me that all of your ideas so far can be
implemented easily within the base bonobo architecture, they could
similarly be implemented using OLE2.

> The cheif problem 
> I see is the assumption about the underlying widget set, that means that 
> the container can just pass a handle to the window, and let the 
> containee scribble to it's heart's content. 

	We assume no widget set in our interfaces, nor do we assume a
windowing system. As long as one app can describe where the other should
render in an arbitrary string, there is no problem.

> I feel this goes against the UNIX
> philosophy. I feel that having a TextViewer item, that is _obsessed_ with 
> displaying text, coupled with a TextEditor which is obsessed with changing 
> text in response to events, is cleaner than a single component that deals 
> with both editing and displaying the text. Maybe it would mean that the 
> editor couldn't care less about fonts, but the viewer wouldn't care what 
> cut copy paste meant.

	There is ongoing work in gnumeric to make it MVC, perhaps you
would like to help with that, as a precursor to the abstraction you
suggest.

> Why is this good for scripting? If you know that your data is coming in a 
> certain format, then you can make optimizations. If you know that a 
> TableView has an interface suited for displaying two dimensional arrays, 
> then you could perhaps 'hijack' it to display and enter convolution
> matrices 
> for an image processor component. (while you can do this with OLE it 
> does bring with it considerable overhead. (ie _all_ of Excel or Word gets
> loaded up))

	Grief; I am all in favour of small components, perhaps again you
can help here with gnumeric to move more of the code to dynamicaly
loadable modules ?

> I apologise for this rant, but I want to see Bonobo be hailed as
> application components done right.

	Fret not; it will be, we are very committed to doing it right.

> PS: can somone clarify this for me.
[ snip rhetorical questions ].

	Accurate but waffle. Have you any specific criticisms of
non-transparency ?

	Regards,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot