Re: Controlling gnumeric from Python

[Jody Goldberg <jody gnome org>]

On Fri, Jan 07, 2005 at 03:41:21PM +0000, John Gill wrote:
> Alexey Goldin wrote:
>
> > Ok, another trick question :-)
> >
> > What is libgnumeric and where do I find it?
> Sorry about that -- Jody has been mentioning libgnumeric for a while 
> now, I suspect it is still partially vapourware.
>
> Gnumeric is built as a model/view/controller + my understanding is that 
> Jody was working towards splitting out the interface to the model part 
> of this to libgnumeric.

That's pretty much the target.  We're actually pretty close now.  To
the point that there will be a libgnumeric (including the gtk
portions) as soon as 1.5.0 branches.  We need to to fix a few things
under win32.  Over time I'd still like to do a real model gui split,
but there are people working on that (Kasal).
 
> Once libgnumeric exists then the next thing to do would be to create 
> wrappers for everyone's favourite scripting language.   The python 
> console would use these wrappers to interact with the model (and hence 
> the current view in the GUI).   Stanalone python  scripts would be able 
> to  use the libgnumeric  interface to  read/write/modify  gnumeric 
> sheets  without a GUI.
>
> The py-gnumeric.c code you are working with is a much earlier attempt to 
> produce python wrappers for gnumeric.  For a long time this has come 
> with warnings that the API is nothing like fixed + that is one major 
> reason why it hasn't had more work done on it.
>
> Basically, the project has been waiting for someone with the time and 
> energy to work out the API.   I think scripting is very high on Jody's 
> wish-list for 1.5, so things might be about to change very soon.

My goal for scripting in 1.5 is taking a slightly different
approach.  I've decided to just make up some gobject based wrappers
that implement the MS Excel object model and api.  Then to use an
automated tool to extract that api and expose it to various
languages starting with python, then the mono framework (for C# and
VB.NET).  After years of waffling about use the Excel API and doing
something new when we'll need to support the old api to handle VBA.