Re: scripting with bonobo

On Mon, 26 Jun 2000, Michael Meeks wrote:
> Date: Mon, 26 Jun 2000 09:40:41 -0400 (EDT)
> To: James Vandenberg <>
> From: Michael Meeks <>
> Reply-To: Michael Meeks <>
> Subject: Re: scripting with bonobo
> 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.

What do you think I've been doing between emails :-) 
I've actually got some simple interfaces worked out, but I've 
been having trouble with some idl. How do you say you want to 
inherit from a particular interface, without having the skels and stubs in
generated code? 
I've tried #pragma inhibit push/pop, but that causes more problems with 
undefined types. eek. 
I thought I'd have a simple text widgety thing this week, having thought
out the 
problems. If I could get the idl past gcc, then I could get you a sample
impl. BTW, you want the IDL I've done so far. 

Don't worry, I know that proof of concept is a lot better than concept

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

You could be right. I have only limited experience of OLE, but it seemed to
be creating Megawidgets from what I saw of it. I could be wrong though.

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

True. libglade is a good example. When I've done a sample of my ideas, you
want a Bonobo::Glade? :-) I was talking about MS OLE. I just worry Bonobo
might fall into the same trap.

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

MVC? Never heard that TLA. I'll help out with Gnumeric tho. Probably should
have a look at how Gnumeric works, given that it appears to be the flagship
app and component testbed :-)

> > 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'll do my best. I'm sorry if it sounds as if I'm "mothering" this idea,
It's just I'm used to having my ideas blasted (usually by clueless jerks).
Sorry. You're obviously not a clueless jerk. 

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

That's very reassuring.

> > PS: can somone clarify this for me.
> [ snip rhetorical questions ].
> 	Accurate but waffle. Have you any specific criticisms of
> non-transparency ?

Yes. It slows you down. If you have to start another app to edit a picture
and then work out how to embed it, a train of though is derailed. (ie, how
to get the letterhead "just right")

> 	Regards,
> 		Michael.
> -- 
>  <><, Pseudo Engineer, itinerant idiot

It's way past my bedtime, and I have a Maths 3 class tommorow morning, 
so I'm going to sleep!


This .sig kindly provided by /dev/random.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]