Copying would be a helpful thing. I ran into similar problems. There is
a workaround.
My copy/paste operation core (sorry, this is c/p from my application so
no setup code shown):
cell = sheet.cell_fetch(col, row)
if cell is not None:
d_cell = d_sheet.cell_fetch(dest_col, dest_row)
# For whatever reason, copying/duping value
doesn't work, so we use other methods
if (debug > 0): print dest_col, dest_row
v = cell.get_rendered_text()
d_cell.set_text(v)
# This works but generates tons of
gnm_style_unref errors
style = cell.get_style()
d_sheet.style_set_pos(dest_col, dest_row,
style)
d_sheet, d_cell is the destination to copy to.
You essentially have to work with parts of a cell.
I can probably help with the introspection annotations, as you've
already seen from the
patches I sent privately. I think if certain core functions are done
first it will enable development
that would uncover other problems.
I have a personal development note document I will share here, since
apparently rough drafts are OK to some of you and hint at problems:
Gnome Introspection notes
- not part of the application
- used scanner driven code
- comments are code
- function names influence introspection interface
- names with "new" mostly result in constructor interfaces that return
full-ownership objects that are easily usable.
- Comments may not export usable interface and this will not show up
as a bug in the application. e.g. allow-none/nullable optional values.
(* I previously described this about inserting "allow-none" in the
defintions)
https://wiki.gnome.org/Projects/GObjectIntrospection#Annotation_System
https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations
Python GI API Reference
https://lazka.github.io/pgi-docs/
Python and introspection
- Applications are C, python is not
- Objects needs to be converted between the two, normally transparent
but sometimes results in unexpected behavior.
Memory Management
- not all objects get exported in a directly usable way
- in .gir file, object definitions tagged return-value
transfer-ownership="full" are directly usable python objects
- other objects may need reference or memory management and can
trigger segfaults
On 04/11/2018 04:42 PM, Morten Welinder wrote:
I tried to write a script to do some basic operations, but I
immediately hit problems in introspection
and/or pygobject. Specifically, something gets terminally confused
over sheet_cell_set_value
leading to a double-free. Even if they fix that right now, it's
going to be years before stable distributions
will see the fix.
In this particular case I might be able to paper over the problem by
interposing a function that copies
its argument instead of taking ownership. That'll slow down python a
bit, but if you're using python
you're probably not that much in a hurry.
The key to getting parts of Gnumeric available via python is to have
accurate introspection annotations
for the relevant APIs. If anyone feels like helping with that, it
would be appreciated.
Morten
_______________________________________________
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
_______________________________________________
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
