Hi all,

I'm looking for help in debugging the python Gtk introspection bindings. I
think I might have found an error in the xml annotation, but I could use
some pointers how to proceed to either prove or disprove it.

The issue is the return value of the Gtk.TextBufferSerializeFunc callback.
The return value documented in the C documentation is "a newly-allocated
array of guint8 which contains the serialized data, or None if an error
occurred". My guess is that python3 bytes are the right type here and the
error message suggests this is correct, except that a single byte is
expected by the language binding.

The following script shows the issue:

##############################

import gi
gi.require_version('Gtk', '3.0')

from gi.repository import Gtk

mimetype = 'x-test/x-serialize'

def serialize_func(rbuffer, cbuffer, start, end, user_data):
        return b'Test 123'

textbuffer = Gtk.TextBuffer()
atom = textbuffer.register_serialize_format(
        mimetype,
        serialize_func
)

textbuffer.set_text('abc')
data = textbuffer.serialize(
        textbuffer,
        atom,
        *textbuffer.get_bounds()
)

print('DATA: %r' % data)

##############################

what I expect:

$ python3 test_serialization.py
DATA: b'Test 123'

what I get:

$ python3 test_serialization.py
TypeError: Must be a single character
DATA: b''

I experimented with returning a single byte instead, on one system I got
segfaults, on the other system I tested the error is gone, but the test
fails silently. I also experimented with other return types, but this just
leads to generic type errors - hence my believe that python3 bytes are
correct.

Digging into the "Gtk.gir" XML annotation I find this definition for the
return type:

<return-value transfer-ownership="none" nullable="1">
<doc xml:space="preserve">[...]</doc>
<type name="guint8" c:type="guint8*"/>
</return-value>


For comparison I look at the return type of
Gtk.Clipboard.wait_for_rich_text() which is also given as "guint8 *" in the
documentation and - more importantly - should return the exact same data as
the buffer serialization function if when were to do copy paste from a text
buffer.

<return-value transfer-ownership="full" nullable="1">
<doc xml:space="preserve">[...]</doc>
<array length="2" zero-terminated="0" c:type="guint8*">
<type name="guint8" c:type="guint8"/>
</array>
</return-value>


So my hypothesis is that in the annotation something went wrong and the
return value of the TextBufferSerializeFunc incorrectly omits the "<array>"
part. My naive guess is that changing it to look more like the second blob
should work.

Off course I tried editing it, but I guess some cache needs to be updated
as well before I can test the effects. So here is where my help request
comes in:

a/ Does the above hypothesis make sense, or am I on a wild goose chase?
b/ How can I change the annotation and test the result?
c/ When testing this, how should the definition look? E.g. I'm not clear
where the array length of 2 comes from - no hint in the C API docs for
that.

Regards and thanks for reading through this,

Jaap
_______________________________________________
python-hackers-list mailing list
python-hackers-list@gnome.org
https://mail.gnome.org/mailman/listinfo/python-hackers-list

Reply via email to