I have a serious Python application running on Gnumeric. This is not a trivial undertaking and I couldn't have done it without access to gnumeric's source code.

I'm not sure if it's still the case but for certain operations it's necessary to patch the existing source. I ported from a VB application and will say it's very difficult to do, especially if you're used to "live" operation where you're watching VB interact with the app. With a patch you can force the python interpreter built in to Gnome to work that way but it's very ugly and will crash frequency due to conflicts in memory management between C and Python.

The more appropriate way is what Morten has shown, running python and invisibly interacting with Gnumeric. Natively without the patch you can't get non-trivial python code to run with a live Gnumeric application via the interpreter in the menu. Running through python is not a problem as Morten's example shows.

The Python GI API Reference is indispensible for coding applications.
https://lazka.github.io/pgi-docs/ You're going to learn a lot about the Gnm and GOffice objects if you proceed.

I'm not sure if this is still the case, (it was with my version, which is 1.12.32 that I am locked into due to patching) but I found it necessary to make patches related to gnumeric's function definitions in order for the Python bindings to work. The introspection interface coding is automated and certain calls need to allow a Python "none" type to be passed, and the definitions in workbook-view.c (and workbook-control.c) didn't have this, resulting in (for example) not being able to save files. I just patched the problems as I found them but for complete conformance dozens of function comments need "(allow-none)" appended to definitions of optional parameters to permit the python GI interface to work correctly.

There are some older examples of code floating about in the docs, but you basically will need to learn how to manage gnumeric's internal model to get most things done (and I still get frequent warnings, likely due to an incomplete understanding of this. I'm a terrible C coder and hackish at best with Python) This isn't the right venue to do a code dump, but to illustrate the point, this is what is necessary to open a spreadsheet, skipping the import statements etc. It leaves you with a couple objects you can use to access the workbook and workbook view:


    s_wbv=Gnm.WorkbookView.new_from_uri(s_uri, None, io, None)

    s_wb = Gnm.wb_view_get_workbook(s_wbv)

It's not trivial. There are other surprises, like the cells value and the cells rendered appearance being separate, so you have to take that into account. I'm sure a second python library that encapsulated basic operations like open, save, copy/paste etc would help immensely but that is a serious undertaking as well.

On 04/10/2018 04:43 PM, Morten Welinder wrote:
If you are looking for easy scripting of such operations, then you will not currently find it. The python and perl plugins have never been used for anything serious as far as I know.

Various parts of Gnumeric are available through gobject introspection and therefore are callable from python and, likely, other scripting languages.   In principle the bindings should work, but I haven't used them much myself. You would be breaking new trail

Here's a sample that just does a numerical computation:

$ python
Python 2.7.12 (default, Dec  4 2017, 14:50:18)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository import Gnm;
__main__:1: PyGIWarning: Gnm was imported without specifying a version first. Use gi.require_version('Gnm', '1.12') before import to ensure that the right version gets loaded.
>>> Gnm.qnorm(0.2,0,1,0,0)


gnumeric-list mailing list

gnumeric-list mailing list

Reply via email to