Re: gtk2-perl

[Guillaume Cottenceau <gc mandrakesoft com>]

goran kirra net writes:

> Guillaume,
>
> On Wed, Oct 16, 2002 at 11:36:11PM +0200, Guillaume Cottenceau wrote:
> > Goran: sorry. You deserve my apologies: your gtk2-perl effort is
> > shaping real well seemingly, and I now think writing my own from
> > scratch would be a loss of time.
>
> no worries. I am old enough to accept diffences in opinion without
> getting offended. If you want to join in welcome aboard, just send
> me a SourceForge userid and I will add you as the 3rd developer
> with CVS (and more) access.

Thanks!

I'm ggc in SF (226437, http://sourceforge.net/users/ggc/).
 
[...]

> > - 'toplevel' moved to Gtk2::Window::TOPLEVEL, etc

[...]

> I using a bit of "Agile programming" here.
> Method:
>       * Just implement something that works.
>       * If it is a better/cleaner/faster/more structured way 
>           to do it just use refactoring
>
> And the perl way is:
> "There are many ways to do it"
> So feel free to wrap or rewrite,
> but keep to old functionality if possible.

Ok. I'll try to understand better how this was done and then
submit a patch.
 
[...]

> > [*] What's your feeling about the .defs serving for

[...]

> Yes,
> again in the "agile programming" tradition:
> I not too keen getting a large untested code mass.
> After all coding is more fun then debugging.
> By using "use cases" (= example code demostrating
> one or a few features) and implement that library
> functionality as needed we get good quality.
>
> * Using autogeneration is the fasted way to produce
>  fasted wrapper implementation of all of Gtk+.
> * Using use cases is the fasted way to produce
>   *high quality* implementation of the most used
>   functionality.
>
> I prefer quality over quantity.

IMHO, you have very good points here.

I'll adopt the same behaviour in my attempt to port our existing
code to gtk2-perl: try to add missing functions etc and submit
the patches and test cases.

About test cases, what is the preferred way? If, say, I need to
add 2 functions to Object.pm, 3 functions to Menu.pm and 1 to
OptionMenu.pm to make a piece of program work, how would you like
the test case to be?
 
[...]

> > Also, probably you should use G_DISCARD (or G_SCALAR if 0 was
> > really the meant value?) as the second argument of the function,
> > I suppose?
> > [*] Also in GSignal.c, in the timeout_closure_run definition, I
> > think the SPAGAIN and PUTBACK macro calls after the function call
> > is unneeded since the function don't use the perl stack pointer
> > thereafter.
> > [*] Also in the timeout_closure_run function, according to
> > http://developer.gnome.org/doc/API/gtk/gtk-general.html#GTK-TIMEOUT-ADD
> > the function will not be called anymore when it returns FALSE, so
> > it seems unreliable to not specify its return value as it seems
> > to do (maybe using more strict compilation switches would help
> > track down those problems?).
>
> Patches welcome.

Here it is (seems to work fine, tested against CVS of
tutorial-examples/progressbar.pl):

--- GSignal.c   15 Oct 2002 21:00:49 -0000      1.1.1.1
+++ GSignal.c   17 Oct 2002 10:10:38 -0000
@@ -79,10 +79,8 @@
        }
        XPUSHs(pc->extra_args ? pc->extra_args : &PL_sv_undef);
        PUTBACK;
-       perl_call_sv(pc->callback, 0);
+       perl_call_sv(pc->callback, G_DISCARD);
        if (event) { SvREFCNT_dec(event); }
-       SPAGAIN;
-       PUTBACK;
        FREETMPS;
        LEAVE;
     }
@@ -169,12 +167,11 @@
        PUSHMARK(SP);
        XPUSHs(ec->data);
        PUTBACK ;
-       perl_call_sv(ec->function, 0);
-       SPAGAIN;
-       PUTBACK;
+       perl_call_sv(ec->function, G_DISCARD);
        FREETMPS;
        LEAVE;
     }
+    return TRUE;
 }
 
 int gperl_signal_timeout_add(char* class, int interval, SV* function, SV* data)


[...]

> Faster and simpler coding!
>
> As I wrote in another discussion, 
> converting to XS is not a big thing.
> Therefor a discussion of the limitations of Inline is useless.

No worries, I'll stop bugging you about that.


[...]

> Thanks for your comments, and welcome to join the project.
> I am not a dictator, my opinions are just opinions,
> and I am easily convinced by working code. 
> That means that contributors have a say regarding the direction 
> of gtk2-perl, non-contributors have not.

Fine with me :).


-- 
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/