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
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 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.
gnumeric-list mailing list
gnumeric-list mailing list