GNOME Bugzilla – Bug 646743
gdkquartz needs objective-c
Last modified: 2011-08-06 00:38:41 UTC
Any code including <gdk/gdkquartz.h> needs to be compiled as Objective-C... Otherwise it will cause errors when trying to #include <AppKit/AppKit.h>
Created attachment 185147 [details] [review] 0001-use-objective-c-for-quartz.patch
So this resolved your problem with gdkwidget.nswindow etc? What did the gtk-macosx people say? I thought a fix like this should belong there.
It "should" resolve it, but my autotools aren't up to snuff to try it... configure.ac:80: warning: macro `AM_CHECK_PYTHON_HEADERS' not found in library configure.ac:101: warning: macro `AM_CHECK_PYMOD' not found in library Do you mean something like hiding the actual Objective-C types in gtkquartz.h ?
Ok, well let me know when you have tested it, and please check with the gtk-osx mailing list that this is the recommended fix. I can't test on Mac.
Hacking in the "-xobjective-c" flag directly into INCLUDES in the gtk/Makefile does make the compilation pass OK, what I couldn't try was the autotools bit.
This is caused by an ill-advised patch from Bug 631088. The creator of that patch filed Bug 632221, where he demanded that we (Gtk, not Gtk-OSX) add -ObjC (does the same as -xobjective-c, but works only in Apple-hacked compilers) to gdk-2.0.pc. As I said in that bug, we can't do that because GObject-introspection will see the flag and fail. It's up to pyGtk to fix your Makefile if you really want to include that header.
Sure, so it looks like this is broken. Looking over the other bugs, I struggle to see the point of having gdk_quartz_window_get_nsviewget_nswindow would be if one cannot use it. Is our use of the function broken?
Anders, if this is all really so unsupported then maybe the recommended way to fix it is to ./configure CFLAGS='-DUSE_QUARTZ -xobjective-c' or some such.
I don't know about broken. At some point the application embedding the native windows has to know what those pointers (NSView* and NSWindow*) mean, so it has to include either directly or indirectly AppKit.h. Once you do that, you need the -xobjective-c flag. There's no need to pass special CFLAGS to configure. You can test for the quartz backend in configure (Anders's patch does this) and set -xobjective-c for the files that include gdkquartz.h. You have to hide that flag from girscanner, so don't put it in any of the global CFLAGS places. You can look at gtk/Makefile.am in the gtk-2-24-quartz branch for a better way to handle it than what's in gtk-2-24.
I think the workaround should be OK (and be backported to pygtk 2.22), at least as long as gdkquartz.h includes that AppKit header and not <objc.h> and "id" or so. The current configure wasn't going to work for gtk3 anyway, since it uses "gdktarget" (just one) and not "targets" (several). Seems natural to want the equivalent nsview/nswindow for xid/handle, even if it has memory/etc issues ?
I'm not going to backport this to 2.22 - PyGTK (me) only maintains one stable release at a time. I am considering applying it to 2.24 series, but I would like to see that you have tested it - perhaps a sample application, build output, reports from other testers if possible. I don't have a mac, so I'd like some wider feedback on this.
Created attachment 185196 [details] [review] 0002-typo-in-configure-variable.patch Addition to previous patch
Besides that I typoed the variable name (oops), the patch does fix the compilation (tested with jhbuild this time, as it has newer autotools)
Created attachment 193336 [details] unpatched build log
Created attachment 193337 [details] patched build log These are build.log with patched and unpatched. (typo fix is included) unpatched version fail to build and patched version go well.
Created attachment 193338 [details] pygtk-demo screen shot (png) Working pygtk-demo screen shot . Feel free to let me know any other information you need.
(In reply to comment #16) > Created an attachment (id=193338) [details] > pygtk-demo screen shot (png) > > Working pygtk-demo screen shot . Feel free to let me know any other information > you need. Thankyou for providing the information I requested. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.