Subject: Re: Scripting, formal docs and reliability
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Sat Jan 27 2001 - 23:30:04 CST
On Sun, 28 Jan 2001, Mike Nordell wrote:
> I just recalled the discussion about scripting. Much of it was a debate of
> what language, or _type_ of language, we should use IIRC. What struck me now
> is that we to be even able to support such an environment we *need* to
> refactor some stuff. Big time.
>
> Let's take the simple matter of inputting one character into a document. You
> just position the cursor where you want the insertion point (IP) to be and
> type away.
>
> Now, how would you do this in a (any) scripting language? You'd position the
> cursor at a specific IP and tell the the WP (AbiWord) to "insert these
> characters".
>
> That's really basic, noone can really argue against this with any substance.
> But, look at our current design. Do *you* know how to "just hook in" this
> scripting engine and make it work? I don't think so.
Actually Mike this is in place already, just waiting for us to make use of
it. All of the functions in EditMethods are static functions and they all
collected into a nice class that allows access to via a string
variable with the name of the function. You get a pointer to the
function in return.
Look at the file...
src/af/ev/xp/ev_EditMethod.cpp
and the EV_EditMethodContainer class. I quote from the comments...
/*****************************************************************
******************************************************************
** The EditMethod mechanism provides essentially a 'call-by-name'
** capability. A key, mouse, menu, or toolbar event may be bound
** to a 'named' function (of type EV_EditMethod_Fn).
**
** EV_EditMethodType provides some crude type-checking (primarily
** this is used by the invoker to check if the function requires
** data ('insertData' can be bound to a key like 'a' but would have
** problems if bound to 'mouse-1-click').
**
** All EditMethod functions have a fixed calling sequence. An
** instance of EV_EditMethodCallData passed to the function is
** used to provide all of the actual data that the function needs.
**
** A EV_EditMethod defines a "named function" and consists of the
** name, a pointer to the actual code, type-checking information,
** and a short description of the function. [I debated whether it
** would be better to put all of these fields as static members of
** a class consisting of just the static function -- I'm not sure
** it matters one way or another. Perhaps the current way will be
** a little easier when it comes time to localize the short
** descriptions....]
**
** A EV_EditMethodContainer is just that, a container for the
** EV_EditMethod's. It provides simple lookup capability. It
** currently has 2 tables of EditMethod's -- a static one (the set
** of our builtin functions) and a dynamic one (intended for use
** by JavaScript later). The container provides the entire set
** of defined functions -- if a function isn't listed in the
** container, it cannot be found or bound to.
**
** The actual tables of defined functions are defined by the
** application and not in this library.
I don't know if there is a place a the cursor at location X function in
EditMethods, but if there isn't I can add it easily and it will be
available for the scripting interface.
I was going to hook this up to the Orbit corba interface of Bonobo in
December but I found I didn't have nearly as much time as I thought I
would and the problem of cutting and pasting List structures turned out to
be much harder than I thought.
>
> This is (yet again) a major reason that we must (not should, *must*)
> redesign the input handlign regarding documents, and that a View is a View,
> a Document is a Document and then we will have to add a "controller" to do
> this kind of stuff.
>
Well certainly fv_View is an overloaded term. It is not really a view onto
the model, it's more of a interface between the input methods and the
controller. Do you have a specfic proposal to split fv_View into
different classes?
> I don't know if this is the right time to start this discussion (again), but
> the longer we wait the more painful and harder it will be.
>
> Comments?
>
It seems to me that the interfaces we need for scripting are in place and
that it is just lack of time that has prevented their exploitation.
This was another of those "gee those SourceGear guys were smart"
discoveries for me.
Cheers
Martin
This archive was generated by hypermail 2b25 : Sat Jan 27 2001 - 23:30:11 CST