Re: Living on the bleeding edge (a bug report)

["muppet" <scott asofyet org>]

Bjarne Steinsbø said:
> A bug report from the bleeding edge.

>   - a small bug in (Gtk2) t/t00.Gtk2 test number 2.  Scalar vs. list
> context.

i had fix for this in my gtk230 testbed, but forgot to commit it.  does the
same as your patch with different syntax...  but you still get the ChangeLog
glory, since i forgot it.  :-)


> More detailed report:
>
> Looking through the ChangeLog of gtk+-2.3.0, I decided this this was
> something I wanted.  So I compiled and installed it.  Yep, I installed
> it in /usr/lib, replacing the stable version.  On purpose.

if you're going to use gtk+ 2.3.x, i recommend lurking on the gtk-devel list
to stay abreast of new happenings.

the new file chooser is cool, and i'm really anxious to use the new
GtkExpander (which i'm considering backporting for my own use).



> First of all I think [the doc generation]
> step should be done when running "make all", not be
> left for "make install".

erm, it may have been that way because of the generation problem you were
reporting --- all of the pods are generated on my system by 'make all'.


> Running the tests revealed some more problems.  There's a small bug in
> test 2 in t/00.Gtk2.  There's something going on with list vs. scalar
> context, where the sub-sub-version (0 in my case) is interpreted by the
> test module as the test result.  The included patch fixes it.

the last item in the list is being used in scalar context; apparently nobody
has ever tested against 2.0.0 or 2.2.0.  i've seen this behavior in lots of
places, actually; i think to handle scalar versus list properly from xsubs you
have to do it by hand.

what do you say to returning a string like "2.3.0" in scalar context, and the
list of elements in list context?


> Test number 4 in t/04.Gtk2 fails with message from gtk+ :
> Gtk-CRITICAL **: file gtkxembed.c: line 188
> (_gtk_xembed_send_focus_message): assertion `GDK_IS_WINDOW (recipient)'
> failed at t/04.GtkSocket-GtkPlug.t line 87.
> I have no idea what this is.  Since focus might be involved, it might
> have something to do with the fact that I've set my window manager to
> use focus-follows-mouse (metacity now calls it "focus model : sloppy"
> :-) ?  A gtk+ bug?  I've seen the same error when installing a previous
> version from cvs, but running gtk+-2.2.4 instead of 2.3.0, so it's not
> 2.3.0 specific.

i don't think it's focus-related or window-manager specific --- i see this on
both Metacity and QuartzWM (the window manager used by X11 on MacOS X), but
only with 2.3.0; my system has 2.0.6, and i no longer have my 2.2.2 testbed. 
GtkSocket and GtkPlug were cleaned up a bit in 2.2.something, so it might have
something to do with that.


> Coming back to the GenPod problem, I verified (hacking a copy of GenPod)
> that TreeViewColumn was indeed involved.

well, yeah, that's because as of 2.3.0 GtkTreeViewColumn implements the
GtkCellLayout interface, but the code you have doesn't register GtkCellLayout
as a GInterface.  thus gperl_package_from_type() is returning NULL in
list_interfaces(), and list_interfaces() isn't taking that very well.

i've committed a fix for that.  basically, check that the returned package
name is not NULL; if it is NULL, get the actual type name, warn that this name
isn't registered, and put that raw C name on the return stack.  this keeps the
output usable without core dumping, and lets us know at the make stage that
something is missing from the bindings.

speaking of that being absent in the bindings, support for 2.3.0 adds 21 new
files to Gtk2.  i have these on deck on my home machine, waiting to go into
cvs as soon as i get the build on HEAD ready to make a branch to support
2.3.x.  before you ask why i'm not supporting 2.3.x on HEAD, it's because
2.3.x is not guaranteed to be API stable, and i want only bindings for stable
gtk+ on HEAD (even if HEAD isn't always stable).  stay tuned, i'll have this
stuff in soon, i swear.


>   perl ...
> which  dumped core and
>   perl -d ...
> went into never-never-land.

this seems to be the case with debugging on linux 2.4.18 -- segfaults cause
some apps to spin rather than dump core.  i don't know if it's something with
the kernel or with threaded apps or what.

> Looking at the xs code of Glib::GType, it worries my a bit that nobody
> seems to free the list returned by g_type_interfaces, but I don't know
> enough to say that this is the problem.

it was indeed a leak, but it wasn't the problem.  now fixed in cvs.



many thanks, this is an excellent bug report!

-- 
muppet <scott at asofyet dot org>