After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 687942 - Add GtkClipboard wait_for_targets_names() method (wait_for_targets() previously was not usable in PyGObject)
Add GtkClipboard wait_for_targets_names() method (wait_for_targets() previous...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 678620
 
 
Reported: 2012-11-08 21:08 UTC by Gonzalo Odiard
Modified: 2012-11-14 10:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (2.54 KB, patch)
2012-11-08 21:08 UTC, Gonzalo Odiard
none Details | Review

Description Gonzalo Odiard 2012-11-08 21:08:55 UTC
Created attachment 228509 [details] [review]
Proposed patch

The g-i bindings is confused trying to return a array of Atoms.
The pygobject ticket related is https://bugzilla.gnome.org/show_bug.cgi?id=678620
A possible solution is implement a new method returning a list with the atom names. That was implemented in the old pygtk bindings.

This patch was discussed in #introspection, but I fill this ticket in the gtk+ because finally the solution depends on gtk+ and not on pygobject.
Comment 1 Martin Pitt 2012-11-13 15:33:40 UTC
@ GTK maintainers: I'd like to try and fix this properly in the annotations and/or pygobject, or whereever things go wrong. So could you please hold off this patch for a couple of days? I'd prefer if we can avoid introducing new API for this.
Comment 2 Martin Pitt 2012-11-13 16:26:12 UTC
Keeping notes for myself: I'm stepping through with gdb. In gtk_clipboard_wait_for_targets() I get a proper GdkAtom** array assembled in the target (out) parameter:

(gdb) p targets
$9 = (GdkAtom **) 0xcb9200
(gdb) p (*targets)
$12 = (GdkAtom *) 0xd2af80
(gdb) p *targets[0]
$11 = (GdkAtom) 0x7c
(gdb) call gdk_atom_name(0x7c)
$17 = (gchar *) 0xc9c330 "TIMESTAMP"
(gdb) p (*targets)[1]
$14 = (GdkAtom) 0x78
(gdb) call gdk_atom_name(0x78)
$18 = (gchar *) 0xd21fe0 "TARGETS"

Examining _pygi_marshal_to_py_array(): The type of the item is void, as expected as a GdkAtom is really just a pointer with nothing behind it:

(gdb) p item_arg_cache->type_tag
$90 = GI_TYPE_TAG_INTERFACE

(gdb) call g_base_info_get_type (iface_cache->interface_info)
$97 = GI_INFO_TYPE_STRUCT

(gdb) p iface_cache->g_type
$93 = 4
(gdb) call g_type_name(iface_cache->g_type)
$94 = (const gchar *) 0x7ffff5d4bf9a "void"

When _pygi_marshal_to_py_array() is done with copying the item into the temporary GArray, the item_arg looks fine:

(gdb) p *((GdkAtom*) item_arg.v_pointer)
$107 = (GdkAtom) 0x7c

but then the marshaller turns it into something wrong:

(gdb) p item_to_py_marshaller 
$108 = (
    PyGIMarshalToPyFunc) 0x7ffff5ddeb59 <_pygi_marshal_to_py_interface_struct>

(gdb) call PyObject_Print(py_item, stderr, 0)
Gdk.Atom<13807488>

I need to leave now, will continue to debug this tomorrow.
Comment 3 Martin Pitt 2012-11-14 05:35:35 UTC
Bug 678620 has been fixed in PyGObject, wait_for_targets() works fine now. So I suggest to close this bug instead of adding new API?
Comment 4 Gonzalo Odiard 2012-11-14 10:21:55 UTC
I agree, closing as fixed.