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

_______________________________________________
gnumeric-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnumeric-list

Reply via email to