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 550754 - need to import GIO types from PyGObject package
need to import GIO types from PyGObject package
Status: RESOLVED FIXED
Product: pygtk
Classification: Bindings
Component: general
Git Master
Other All
: Normal major
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2008-09-03 22:46 UTC by Paul Pogonyshev
Modified: 2008-09-08 20:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
not-working patch (923 bytes, patch)
2008-09-03 22:47 UTC, Paul Pogonyshev
needs-work Details | Review
patch (2.42 KB, patch)
2008-09-04 19:05 UTC, Gian Mario Tagliaretti
needs-work Details | Review
patch that solves it but depends on bug 551056 (2.45 KB, patch)
2008-09-05 22:41 UTC, Paul Pogonyshev
none Details | Review
patch that solves it but depends on bug 551056: second revision (2.49 KB, patch)
2008-09-07 21:34 UTC, Paul Pogonyshev
committed Details | Review

Description Paul Pogonyshev 2008-09-03 22:46:30 UTC
This is pointed out by Gian.  Several 2.14 methods need access to GFile and GIcon.  Non-working patch follows.

In general, how this is done by other codegen users?  I guess there are libraries that need acces to PyGTK types for their bindings, no?
Comment 1 Paul Pogonyshev 2008-09-03 22:47:44 UTC
Created attachment 117970 [details] [review]
not-working patch

This patch doesn't work.  The wrappers are now generated by codegen but cause compilation errors:

gtk.c: In function `_wrap_gtk_icon_theme_lookup_by_gicon':
gtk.c:51309: error: `PyGIcon_Type' undeclared (first use in this function)
gtk.c:51309: error: (Each undeclared identifier is reported only once
gtk.c:51309: error: for each function it appears in.)
gtk.c: In function `_wrap_gtk_image_set_from_gicon':
gtk.c:54007: error: `PyGIcon_Type' undeclared (first use in this function)
gtk.c: In function `_wrap_gtk_status_icon_set_from_gicon':
gtk.c:103200: error: `PyGIcon_Type' undeclared (first use in this function)
gtk.c: In function `_wrap_gtk_file_chooser_set_file':
gtk.c:108176: error: `PyGFile_Type' undeclared (first use in this function)
gtk.c: In function `_wrap_gtk_file_chooser_select_file':
gtk.c:108195: error: `PyGFile_Type' undeclared (first use in this function)
gtk.c: In function `_wrap_gtk_file_chooser_unselect_file':
gtk.c:108212: error: `PyGFile_Type' undeclared (first use in this function)
gtk.c: In function `_wrap_gtk_file_chooser_set_current_folder_file':
gtk.c:108229: error: `PyGFile_Type' undeclared (first use in this function)
gtk.c: In function `_wrap_gtk_image_new_from_gicon':
gtk.c:120557: error: `PyGIcon_Type' undeclared (first use in this function)
gtk.c: In function `_wrap_gtk_status_icon_new_from_gicon':
gtk.c:120596: error: `PyGIcon_Type' undeclared (first use in this function)
Comment 2 Gian Mario Tagliaretti 2008-09-04 19:05:09 UTC
Created attachment 118038 [details] [review]
patch

this should fix both
Comment 3 Paul Pogonyshev 2008-09-04 19:49:23 UTC
Comment on attachment 118038 [details] [review]
patch

It does compile fine, but segfaults in runtime on access to the types.

>>> import gtk
>>> gtk.icon_theme_get_default().lookup_by_gicon(None, 0, 0)
[Switching to Thread 1075475200 (LWP 18559)]

Breakpoint 1, _wrap_gtk_icon_theme_lookup_by_gicon (self=0x3, args=0x3, kwargs=0x3) at gtk.c:51316
51316       if (!PyArg_ParseTupleAndKeywords(args, kwargs,"O!iO:GtkIconTheme.lookup_by_gicon", kwlist, &PyGIcon_Type, &icon, &size, &py_flags))
(gdb) p PyGIcon_Type
No symbol "PyGIcon_Type" in current context.
(gdb) p _PyGIcon_Type
$1 = (PyTypeObject *) 0x0

Why did you remove 'import ... as ...' line?  Maybe reverting that and adding similar lines for new types will solve this?
Comment 4 Gian Mario Tagliaretti 2008-09-04 20:14:08 UTC
importing ... as ... basically only does what I've put into #ifdef.
I've done it like that otherwise compile against pygtk < 2.14 will fail.
Comment 5 Paul Pogonyshev 2008-09-04 20:28:00 UTC
No, that's not all.  See beginning of pygtk_register_classes() in generated 'gtk.c' --- it actually initializes variables.  Your patch only declares variables, but they never get initialized, so we have a segfault on accessing NULL type.

I will look if codegen supports conditionals.  Looks kinda ugly to duplicate all that code only to make it dependant on version.
Comment 6 Paul Pogonyshev 2008-09-05 22:41:30 UTC
Created attachment 118128 [details] [review]
patch that solves it but depends on bug 551056

This solves it but only if patch in but 551056 is accepted too.  I.e. this one uses new conditional importing.
Comment 7 Paul Pogonyshev 2008-09-07 21:34:07 UTC
Created attachment 118255 [details] [review]
patch that solves it but depends on bug 551056: second revision

A little changed configure magic: now it checks if PYGOBJECT_DEFSDIR is defined first and emits correct diagnosis messages.  Also removed accidental CODEGENDIR evaluation duplicate.
Comment 8 Paul Pogonyshev 2008-09-08 20:33:42 UTC
Sending        ChangeLog
Sending        configure.ac
Sending        gtk/Makefile.am
Sending        gtk/gdk.override
Sending        gtk/gtk.override
Transmitting file data .....
Committed revision 3037.

2008-09-08  Paul Pogonyshev  <pogonyshev@gmx.net>

	Bug 550754 – need to import GIO types from PyGObject package

	* configure.ac: Determine if `gio-types.defs' is installed as part
	of PyGObject.

	* gtk/Makefile.am: Use it to register GIO types if installed.

	* gtk/gdk.override: Make gio.AppLaunchContext import conditional.
	Add conditional import of gio.Icon.

	* gtk/gtk.override: Make gio.MountOperation import conditional.
	Add conditional imports of gio.File and gio.Icon.