Idea for plugin capabilities

I've written macros for the Applix Unix-spreadsheet but use Gnumeric these days.
The Applix macro-language is a kind of BASIC, and I had a hard time writing even
reasonably simple functions. I was told that Lotus 1-2-3 and Microsoft Excel also
used BASIC as their extension languages.

For example, one of my Applix macros sorted a sequence of rows or columns of the
current sheet. To sort rows, I would just select a sequence of cells that span
them, and vice-versa to sort columns. Here's an example:


In this case I've selected cells that span 4 rows. My sort macro would reorder
these 4 rows using the selected cells as the sorting keys. The direction of the
sort is detemined by which direction I selected the 4 cells: if I selected top-
to-bottom, then the row containing the cell containing the key with the largest
value would end up on the bottom. I found this kind of sorting to be simpler and
more useful than the sort functions built into any spreadsheet I've seen.
It wasn't too hard to write this in Applix BASIC, but I wanted to write some
more complex macros that involved numerical transformations and there was no way
I could write these in BASIC. Further, I've moved to using Gnumeric for various
reasons. I haven't found enough information on Gnumeric & Python to figure out
how to use them to write extensions.

What I'd like to see in Gnumeric, which to me would be more in the spirit of
Unix, would be the ability to add extensions that just pipe the contents of the
spreadsheet, in XML format, into the STDIN of a subprocess, and then load the
result of STDOUT back into the spreadsheet. Then I could write my extensions as
standalone C++ or Perl utilities and use invoke them with pipes.

When I want to create a new extension, I would just assign a button or a menu
entry to invoke it, and a name to go with it. Then I would assign a Unix-command,
possibly including parameters, to be spawned when I invoke the extension. Last,
I would specify the scope of the data that would be passed to the STDIN of the
subprocess: (1) the current selection, (2) the current sheet, or (3) the entire

In my sorting example, I'd define a button called "sort", and when I click on it,
it would execute a program "my_sort" and pass the XML description of the current
sheet into its STDIN. Then Gnumeric would load the STDOUT from "my_sort" into the
current book.

What do y'all think of this idea? I'd *hope* this would be easier to implement
than having an extension language, or to require us to recompile Gnumeric with
our own extensions as libraries. On the other hand, I may be optimistic to
assume that I can understand the Gnumeric XML conventions well enough to use it
as the input/output language of my utilities.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]