gnumeric API: (was python scripting)

[Adrian Custer <acuster nature berkeley edu>]

Hey all,

Some random thoughts about accessing gnumeric. These are mostly notes to
myself about how jworkbook should work for easy access but are related
to scripting, in some far off way. And related to export functionality
(into tables). And related to jworkbook and how to save the coding
effort of allocating efficient storage.

The discussion centers around a cell-by-cell approach. 

The simplest way to access the array of data, formatting, bordering and
other layout elements of gnumeric is cell by cell. It may be slower but
it's simple to understand and to work on. Ranges are fabulous for border
boxes and other information, are quicker operations and are necessary
for storage but understanding them takes a bit longer than absolutely
required. (For instance, if you are satisfied dumping data cell by cell
into a worksheet and don't require formatting). 

So the quickest way to expose a gnumeric worksheet model is to allow all
operations possible to operate at the cell level. This way a slow dump
to any other array format is a nested loop of 

for each worksheet
        for each [row,col]
                for each [col,row]
                        get/put/alter/...  cell_ijk

for pivot tables it's merely more dimensions.

Now, it's a terrible way to store data. So the data need to be cleaned.
Now the best place to alter data is from within gnumeric since that code
knows best how 
        1) gnumeric works
        2) data can be stored efficiently.
So I see two ways that gnumeric can do this, both related to exposing
the scripting api. 

1) gnumeric parses inefficient files and spits out an efficient file.
This requires a file format that is cell by cell, that gnumeric reads,
calls its own scripting api which works cell by cell to build the
efficient model and gnumeric then dumps that efficient model to a
compact .gnumeric file.

2) gnumeric exposes to as many languages as possible an api and gnumeric
can be run with no view. The other languge code calls the api for
cell-by-cell operation. The api uses the internal scripting api to build
the efficient model cell by cell and the api includes a save-to-file
call.

Which means the scripting api needs to work cell-by-cell. This api
simply must check, for each attribute being altered, if there is a
neighbouring region to which it can be attached. Since these regions
need to be orthagonal, you may have to check arbitrarily deep in the
rectangular neighbourhood to see if the attribute can be rebuilt into a
more compact range.

That's it. Probably won't make sense next time I look at it. 

Congrats on 1.1.20!


On Thu, 2003-08-21 at 22:33, gsowww yahoo co uk wrote:
> On Fri, Aug 22, 2003 at 01:00:55PM +1000, Charles Twardy wrote:
> > > Actually that is already supported, and documented.  You can create
> > > spreadsheet functions in python and register them with Gnumeric.
> > > Pass a range as an argument and you'll be able to interact with it
> > > at the other end in python.  The interface could use a bit of
> > > tuning, but the functionality is there.
>
> It's more a macro language that I'm thinking of myself.  Creating
> functions is useful (I used excel a number of years back to interpolate
> data similar to pressure contours on a weather map).  What I'm look for
> at the moment though is more along the lines of creating a quick macro
> to copy the value entered into the current location to the end of a
> table somewhere else, or to run a preset filter on some data and so on.
>
> GSO
> gsofwd email com
>
> _______________________________________________
> gnumeric-list mailing list
> gnumeric-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnumeric-list