Re: scripting with bonobo

[James Vandenberg <james vandenberg dropbear id au>]

On Mon, 26 Jun 2000, Dirk-Jan C. Binnema wrote:
> Date: Mon, 26 Jun 2000 13:08:17 +0200
> To: gnome-components-list@gnome.org
> From: "Dirk-Jan C. Binnema" <bulkmail@dds.nl>
> Reply-To: djcb@dds.nl
> Subject: scripting with bonobo
> 
> Hi all,
> 
> In the plan for Bonobo world domination, scripting is
> pretty important, I guess (where 'scripting' means programming using
> some extension language, within the context of some program, such as
> Emacs elisp or Gimp ScriptFu).

Scripting is king! With a scripting interface, you can automate many 
tasks, making yourself more productive. (I have simple shell scripts 
for creating C++ class skeletons, newclass FooBar is better than doing 
all the other crap, and it's more consistent.) Without scripting, You'll 
find yourself getting frustrated with an app when you need to do a lot 
of the same sort of stuff. I think scriptability is an extremely important
goal.
 
> It seems that scripting will used in more and more programs, ie. gb in
> gnumeric and (perhaps) some yet-to-be-decided language in Abiword. It
> seems though that the same problem (embedding language X in
> application Y) is solved over and over again. 

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

> What would be nicer to have one approach to be able to embed any
> language in any application. One such approach is Guile -- it's very
> easy to embed the Guile interpreter in your application. Now, to
> support your favorite scripting language, *all* you have to do is write
> a translator Perl->Scheme, Python->Scheme etc. However, this is
> non-trivial (to say the least). There have been some attempts at
> translators (tcl, javascript, ctax), but I don't think these are
> 'production quality'. In my o-so-humble opinion, the Guile-approach is
> not going to work. (This is _not_ to say Guile is useless - Guile is a
> very nice embeddable Scheme interpreter for which the Guile developers
> deserve a lot of admiration; it's just the translators-part that's not
> going to work, IMHO).
> 
> So what other approaches exist? What about defining some
> idl-interfaces for scripting languages and their host application?
> This is approach chosen by the MS ActiveScript mechanism. The
> embeddable language will do stuff like (*very* simplified example): 
> 
> interface EmbeddableLanguage {
>     void initialize ( in Host host );
>     void run ( in string script );
> };
> 
> interface Host {
>     void on_error  ( in Error error );
> };

Guile is baad, use perl! :-) I agree that having a decent and uniform 
interface to a scripter is a good thing.

> Now, the interesting thing is of course how to get application
> specific stuff in your scripting environment, e.g. your 'Sheet'-object.
> To do that, we can add another method to EmbeddableLanguage:
> 
> 	void add_object ( in Unknown unk, in string known_as );
> 
> and you can offer a reference to your Sheet, with some friendly name
> "sheet" to your scripting environment, in which you could then write 
> 
> 	sheet.do_something_useful(1,2,3)
> 
> The beauty of the mechanism is the loose binding between host app and
> scripting language. As long as both implement the interfaces, you can
> choose any language/app combination. In my previous job, I wrote a
> WinNT mail-router in C++ that implemented the Host interfaces, and was
> able to script it in VBScript, JavaScript, Perl, Python and even
> Haskell! While MS developed the ActiveScripting stuff, unfortunately
> they don't use it for Office - in Office VBA seems hardcoded.

Good way of doing things. It does mean however that any internal object 
you wanted to allow out would need a bonobo interface. (I think so,anyway)

<RANT type=PersonalIdea disclaimer="These are not official bonobo 
ideas, and as such, should only be taken as suggestions and criticism">
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. Then we could 
give all GTK+ objects a corba interface using these data objects. Then 
the actual components use these interfaces. With any luck you could put 
a filter type component between the data source and the data sink(GTK+
 widget). Something along the lines of shell pipes. GUI pipes! I can see 
the faq now : "Gui Pipes? Won't I have to clean them to stop my data 
getting stuck?" But we could have more than one sink reading one 
peice of data, so that you could see the data as it flowed through the 
pipe. Problem is, you'd need to keep the editor and the view side of 
things separate. How could this help a scripting model? The scripting 
engine would only need to deal with the standard data structure, editor 
and view interfaces. And even if you needed to work on data without 
involving the mother editor, you could grab the data and fiddle with that 
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. 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. 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. 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.

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

I think combining Portable Scripting, Data Objects and Universal Viewers 
could provide bonobo with a powerful developement framework, that 
has a philosophy close to that of UNIX, and the ability to do things that
you wouldn't expect with a UNIX background.

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

> In the Unix environment, probably Perl and Python are the easiest to
> write EmbeddableLanguage glue for, as they have working
> CORBA-bindings. Bash will be a little harder ;-) 
> On the Host side, an application must be able to serve it's 'object
> model' as a Bonobo (CORBA) object. This may not be trivial for all
> apps.

If we can ensure that the apps do it right, I can't see a problem. It could
be that I haven't seen it yet. If so, somebody tell me before I say
something
stupid.
 
> So, do any of you think this is useful for application scripting in the
> Bonobo era? If so, I could write down some more complete IDL
> interfaces.

Yes. A good scripting interface that can be found in nearly every 
application would be excellent. Trust me, a large part of a _powerful_
desktop is a way to automate repetitive actions. Remember how 
people complained when WinMacros didn't make it to Win95, and 
the subsequent introduction of windows scripting host. in Win98. It's 
also a good way of customizing an app. Anybody who uses emacs, 
just check out how much of it is actually elisp. I'd wager more than
60% Some peoples ~/.emacs can grow to over 10K in size. But that's
some of the appeal of emacs, it's incredible extensibility. (note to emacs
vs vim flamers, I use vim on the command line, and Xemacs in the gui.
I don't see which one is better, if any.) 

Back on topic. I think module Bonobo::Script is a good aim. Go for it.

> Cheers,
> 	Dirk-Jan.
> 

Seeya
JamesV
--
PS: can somone clarify this for me. Gnome should be 
extremely powerful, but unobtrusive? A desktop so 
powerful it dissappears? One of my biggest gripes is 
programs that get in the way, usually by being far too 
helpful or far too rigid or limited, sure, give me the ability
to see my speling goofs, but allow me to chuck it out if I 
don't like it. I don't want a dumbed down application! I want 
an application that does what I say, whatever I say, 
and stays out of the way. That's what I want. If I tell it to jump,
I don't want it to ask "high, long, or triple?" I hope Gnome
encourages unobtrusive software. Like a good assistant. 
It knows exactly what you need. This is too long for a PS
I'm going to shut up. J