Questions debugging introspection Gtk bindings



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,
	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 



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