On Dec 21, 2007, at 5:35 PM, Jeffrey Ratcliffe wrote:
On 20/12/2007, muppet <scott asofyet org> wrote:You'll also want to hush the "unused variable `class'" warning by not including the line "SV * class" in the argument listing of gtk_image_view_new().Thanks.
No problem.
I hope I have now finished the bulk of the work. The remaining bindings compile without error. However, the only constructor that is passing a correctly blessed object is the main Gtk2::ImageView one, all the others pass 'Glib::Object::_Unregistered::Gtk*', so in testing isa, I get failures like: # Failed test 'The object isa Gtk2::AnimView' # in t/animview.t at line 23. # The object isn't a 'Gtk2::AnimView' it's a 'Glib::Object::_Unregistered::GtkAnimView'
I assume I am missing something fundamental, and would be grateful for a hint.
Hrm. It looks like gtkimageview.h doesn't follow the convention of one-stop header for everything in the gtkimageview library; to get GTK_TYPE_ANIM_VIEW #defined , you have to #include gtkanimview.h separately. The code generated by Glib::CodeGen in register.xsh wraps the registration of the object type for GtkAnimView in #ifdef GTK_TYPE_ANIM_VIEW. ImageView.xs, which #includes register.xsh, doesn't #include gtkanimview.h, so that macro isn't defined, and we simply don't register the GType to package mapping.
Simple solution: #include gtkanimview.h in ImageView.xs.More proactive: #include gtkanimview.h in gtkimageviewperl.h, and make sure you use gtkimageviewperl.h everywhere instead of duplicating the #include lines for all the various headers. The attached patch does this. One reason to do this is that anybody wanting to create an XS extension that builds atop yours (as yours builds atop gtk2perl.h) will expect everything it needs to come through one header, gtkimageviewperl.h. More immediately, this ensures that every file inside your project sees the same set of preprocessor definitions at build time. (Repeat after me: the C preprocessor is Evil.)
Oh, and check your license comment blocks; you've attributed your binding work to the gtk2-perl team as of four years ago, and have a CVS $Header:$ tag showing me as the most recent author, in June 2003. ;-)
A bigger issue: namespacing. The classes you define are Gtk2::ImageView, Gtk2::ImageToolSelector, etc. That is, they are right in the Gtk2:: namespace, waiting for potential name clashes if and when gtk+ adds something called GtkImageView. Now, of course, the same problem exists with the upstream library, but instead of taking up a bunch of slots in the Gtk2:: namespace, how about doing something like this, instead?
GtkImageView -> Gtk2::ImageView
GtkImageTransp -> Gtk2::ImageView::Transp
GtkImageToolPainter -> Gtk2::ImageView::Tool::Painter
So, attached:
fix-includes.patch: make everything include gtkimageviewperl.h instead
of various files.
requirements.patch: in Makefile.PL, look for gtkimageview 1.5.0, since these bindings won't compile against older. You can play with ExtUtils::PkgConfig and look at other modules for hints on how to make your bindings compile against multiple versions of the upstream library.
transp-map.patch: GtkImageTransp was listed incorrectly in the maps file as mapping to the package name Gtk2::ImageView. Fix that.
interactive.pl: a quick transliteration of gtkimageview/tests/ interactive.c. Note that the way this program uses the GtkImageTransp values in the UI manager actions doesn't really play nicely with perl syntax for enums, so there's a terrible, evil, horrible hack in its place. If you golf this down to more perlish code, using closures and such, you can sidestep the problem.
Attachment:
interactive.pl
Description: Text Data
Attachment:
fix-includes.patch
Description: Binary data
Attachment:
requirements.patch
Description: Binary data
Attachment:
transp-map.patch
Description: Binary data
--One, two, free, four, five, six, sebben, eight, nine, ten, elebben, twull, fourteen, sickteen, sebbenteen, eightteen, elebbenteen, fiffeen, elebbenteen!
-- Zella, aged three, counting to twenty.