Re: misc fixes

[muppet <scott asofyet org>]

On Oct 3, 2005, at 11:27 PM, gtk-perl schmorp de wrote:

> On Sat, Sep 24, 2005 at 06:47:45PM +0200, Torsten Schoenfeld  
> <kaffeetisch gmx de> wrote:
>
> > Most converters complain loudly if they stumble upon an undefined  
> > value,
> > yes.  That's been our policy because it's the correct thing to do in
> > nearly all cases.
>
> "Nearly all cases" seems to be very wrong, though, at least with  
> regards
> to structure converters, where the opposite seems the norm.
>
> I'm not arguing the policy, but that policy incidentally makes correct
> programs broken when a mistake is made (and such mistakes are  
> extremely
> common in Gtk2), while the opposite policy would not break correct  
> code,
> but would only allow broken code (actually, the gtk+ functions  
> themselves
> usually complain loudly).
>
> A policy of allowing undef when in doubt/per default and using the
> non-_ornull functions would result in the same result if there are no
> bugs, and in a rather more useful situation if there are bugs.

The policy (if you want to call it that) in place is a continuation  
of the Gtk-Perl practice.  As i understand it, the idea was to  
prevent the gtk+ nastygrams from coming out and scaring or confusing  
perl developers with no C experience.

A drawback of what you propose is that error messages will have C  
type names rather than perl type names.  Some perl developers simply  
don't know what "NULL" is.

An advantage of what you propose is that gtk+ assertions would print  
out with somewhat more helpful messages, like "Gtk-CRITICAL:  
assertion `window != NULL' failed" instead of "undef is not a  
Gtk2::Window".  HOWEVER, this is only true if you're using a gtk+  
that was compiled with the assertion macros in place.  Some crazy  
people compile those out, so passing undef would result in a core  
dump, which is very unfriendly.


But, you're talking more about structure wrappers than function  
wrappers.  Allowing NULL in a structure can be even harder for a perl- 
only user to track down, because the resulting breakage may not occur  
for quite some time.  The real fix is to have better upstream  
documentation of the lifetime and value constraints of structure  
members.  In the absence of this, we wind up having to dig through gtk 
+ source code to find out what to do, and in some of those "fringe"  
cases, it doesn't seem worth it --- for example, gdk_gc_set_clip_mask 
() and gdk_gc_set_clip_region() haven't been touched since before the  
code was in sourceforge's CVS!

In the case of SvGdkGCValues(), it looks like all that is needed is  
changing this pattern

   if ((s=hv_fetch (h, KEY, len, 0)) && SvOK (*s)) {
       v->KEY = SvTHISTHING (*s);
       mask |= GDK_GC_THISTHING;
   }

to

   if ((s=hv_fetch (h, KEY, len, 0))) {
       v->KEY = SvOK (*s)
                ? SvTHISTHING (*s)
                : NULL;
       mask |= GDK_GC_THISTHING;
   }




> > When a function does allow NULL, we simply add
> > _ornull manually -- just like you did in the patch.
>
> Is there any reason why it didn't get applied?

Time, i'm guessing.  I didn't get a chance to look at the original  
patch in any detail until tonight.


> In any case, I attached it again, with an additional similar fix.

xs/GdkEvent.xs:
The changes to get_time() look all right.  To pass undef, you'll have  
to call it like "Gtk2::Gdk::Event::get_time(undef)", correct?

(get_|set_)?time() and (get_|set_)?state()  need apidoc comments to  
list their signatures properly.


xs/GdkGC.xs looks alright.


xs/GdkPixbuf.xs is good.  That needs to go into stable as well as HEAD.
I can't help but point out that this bug would've been prevented by  
the sink semantics for GObject currently being discussed on gtk-devel- 
list.


xs/GtkX11.xs will have to go into HEAD, since it adds API.
gdk_net_wm_supports() is bound as a function, which, right or wrong,  
is not conventional in Gtk2.



> > (In the bright, not-so-distant introspection future, this will be
> > automatic: parameter definitions state if NULL is allowed or not.)
>
> Actually, most breakage isn't in parameters, it seems.

Well, the parameters are the easy ones.

What Torsten was alluding to, though, is that the introspection API  
describes structure members as well, so that it would be handled by  
the binding engine from upstream descriptions and not by mistake- 
prone hand-coding on our part.  Although, now that i think of it, i  
don't remember for certain if it tells what valid values for those  
members are.


> In any case, this doesn't solve the original problem on having no  
> clear
> documentation on this (in gtk+) and Gtk2 being unusable for nontrivial
> scripts due to these issues (fortunately, I seem to be the only one  
> using
> Gtk2 for more than a prebuilt widget toolbox, so it isn't a big  
> problem,
> as I can fix it).

I think it's more that people tend to use C or C++ for "heavy  
lifting" with gdk, so the darker recesses of the API in perl are not  
as well field-tested as the rest.  We exercise everything that we can  
in the tests, but it's hard to get all use cases down.


> OTOH, fixing it is a bit frustrating if my patches get ignored, as  
> is the case, as so far no comment on the patch did arrive nor was  
> it applied.

To be fair, you did so "no hurry".  ;-)


--
Meg: Brian!  Chris picked his nose and keeps trying to touch me with  
his finger!
Chris: What good is mining nose gold if I can't share it with the  
townspeople?
   -- Family Guy