Re: misc fixes

[Marc Lehmann <schmorp schmorp de>]

On Tue, Oct 04, 2005 at 01:24:50AM -0400, muppet <scott asofyet org> wrote:
> 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:
> >
> > 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)
   
(I didn't call it policy, btw.)
   
> 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.

I am not proposing either, I am just pointing out that the reverse policy
would, when correctly implemented, result in the same behaviour. Only when
there are bugs in the Gtk2 module will the behaviour differ.

That (C) error message would only occur when there was a bug in Gtk2
interface AND the perl program.

> 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.

Again, only if there were a bug in the Gtk2 interface in the first place.

Right now, those bugs lead to correct code being unusable till it's fixed
in most cases.

> But, you're talking more about structure wrappers than function  
> wrappers.

I was just replying to a context where both structure wrappers and 

> 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.

Which resulting breakage do you talk about? The breakage is already there,
in Gtk2, and consists of not allowing undef where it is valid. It's easy
to track down, too: the program will barf immediately.

> The real fix is to have better upstream documentation of the lifetime
> and value constraints of structure members.

That makes no sense at all. Changing upstream _documentation_ will not
magically fix the Gtk2 module. Wether documented or not, the code needs
change.

On why it isn't documented I can only guess, but in the cases I've seen
it's simply obvious that you can pass NULL once you _use_ those functions
(in all those cases I did assume that undef would work).

It's much less obvious when you are writing interface code for hundreds
of functions mostly blind, and I guess that the author of the gtk+
documentation didn't target that case.

> + 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!

I can't follow that either - do you hint that not too many people use those
functions so it isn't worth to fix them?

In any case, if those fixes are deemed unworthy, then I can stop wasting
my time with bugfixes in the future.

We are not talking about the few cases where you can work around the
problem, but there are many cases where people simply cannot use the
function as they are wrong - for example, gdk_gc_set_clip_region breakage
is workaroundable, by providing a real clip region, but that needs to be
updated. Other cases are not workaroundable.

I am sure tha majority of users use Gtk2 the same way they would use Tk. But
the greatness of Gtk2 was that it wasns't just a primitive toolbox but an
interface to gtk+. There are not many gtk+ programs that don't create their
own widgets, and for that to work you need to be able to modify your GC at
times.

In my case, I am writing a simple image viewer, and to properly implement
the refresh I have to set the clipping region on redraws otherwise I get
bugs.

When these cases are not really seen worth the effort, people are simply
forced to reimplement parts of Gtk in their own modules (as I have to do
till a Gtk2 + fixes has been released).

> 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;
>    }

Seems so.

> 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?

Probably. I'd probably do it differently, but the Gtk2 API policies of
making everything a method never made sense to me. I'd guess the Gtk2-way
would be "Gtk2::Gdk::Event->get_time" or "Gtk2::Gdk::Event->get_time
(undef)", both of which would be implementable.

> xs/GdkPixbuf.xs is good.  That needs to go into stable as well as HEAD.

Hmm - any reason why the other bugfixes shouldn't go into stable as well?

> 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.

That is probably an oversight on my part, feel free to make it a method.

> lifting" with gdk, so the darker recesses of the API in perl are not  
> as well field-tested as the rest.

Well, I know. Everytime I touch Gtk2 I stumble over those, which is not a
problem as long as I could apply fixes, or had fixes applied.

> We exercise everything that we can  
> in the tests, but it's hard to get all use cases down.

Sure, the joys of software development....

> > 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".  ;-)

Well, I am a bit puzzled on why there was time to do a new Gtk2 stable
release which such ground-breaking fixes in example code and the
testsuite, while actual code-bugfixes were ignored.

Yes, I know I am the only perl-widget-writer in existance (or so it
seems), but I do implement the fixes I complain about in most cases,
too...

-- 
                The choice of a
      -----==-     _GNU_
      ----==-- _       generation     Marc Lehmann
      ---==---(_)__  __ ____  __      pcg goof com
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE