Re: TODO / Wishlist

["" <nick savs net>]

Kevin Connor Arpe wrote:
> Hi,
...
> I see this:
> Scripting. After some vacilation trying to decide between wrapping
> Gnumeric's object model, and providing something that is VBA compatible,
>  the latter won. We'll export an api in C that is compatible with the widely
> used VBA interface, and wrap it in several languages (Python, VB.NET, and
> C# are likely candidates).
>
> Can someone flesh this out a little?  Or point me to old posts on the
> matter.  I am familiar the Excel VBA model, but I can't get my head around
> those two sentences.  Is the goal to expose the Gnumeric object model as
> the VBA model via a C interface.  Then other scripting languages (Python,
> Perl, etc.) can build from this object model?

I hadn't seen that bit before :/

I've been looking at generating python bindings for Gnumeric's object model using pygtk codegen techniques, 
and have some prototype code and notes (all the gotchas etc. I encountered during prototyping), along with a 
rough list of what order to tackle header files in (derived from poring over doxygen header and type 
dependency graphs) which I've been meaning to stick up on a wiki somewhere so I don't keep holding up the 
show :(

There are 2 problems on my end: (1) Damn global credit crisis... my day job has been insanely busy (2) If you 
look at the function type parsing code in h2def.py, it doesn't handle pointer returns (eg. char 
*some_function();). I assume there's insider knowledge I'm missing, since PyGTK obviously generates bindings 
for the GTK+ API which is full of pointers, but the documentation is nonexistant, I haven't got around to 
email the guys, and every weekend something seems to suck up my time...

> This is a huge project by itself.  Nevertheless, I am interested.  Please let
> me know where things stand and where I can begin to read code and poke
> around.  I'll need to start by just reading the code base for a while to get a
> feel for how it works.

You can build "libspreadsheet" from the Gnumeric source which looks to me to be a first pass at separating 
out and bundling up all the glib-style objects used in Gnumeric. In include/libspreadsheet-1.10/spreadsheet 
you have the individual headers. As an example, I can do the following after generating a (fairly useless) 
python module:

Python 2.4.4 (#2, Jan  3 2008, 13:36:28)
[GCC 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
> > > import pygtk;  pygtk.require("2.0")
> > > import libgnumeric
> > > dir(libgnumeric)
['__doc__', '__file__', '__name__', 'gnm_dump_func_defs', 'gnm_init', 'gnm_pre_parse_shutdown', 
'gnm_shutdown']
> > > libgnumeric.gnm_init(True)

There's also the "python console/plugin" work in plugins/python-loader/py-gnumeric.c which has semi recent 
commits, and they seem to be manually generated python bindings to some of the parts of gnumeric which work 
while gnumeric is running (and they have GTK+ signal handling and funky stuff). That looks like a lot of 
manual work to me and I would guess it's not maintainable (lots of work to understand, Gnumeric object model 
is huge and changing, etc), but it actually _exists_ unlike what I've been trying to work on ;)

I reckon the sanest thing to do would be to get the heavy lifting done with code generation (as in 
http://www.ibm.com/developerworks/linux/library/l-wrap/) and then build a pythonic end-user API on top of 
that. We could learn a lot from Java-GNOME IMHO 
(http://java-gnome.sourceforge.net/4.0/doc/design/1a-Homework.html). When/if I get more time and get over the 
h2def problem above, I'd love to be hacking on this, but If other people have more time or are making heaps 
more progress, let me know.

Nick