Re: gtk2-perl

goran kirra net writes:


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.


I'm ggc in SF (226437,

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


I using a bit of "Agile programming" here.
      * 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


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

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, 3 functions to and 1 to 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
[*] Also in the timeout_closure_run function, according to
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

--- GSignal.c   15 Oct 2002 21:00:49 -0000
+++ GSignal.c   17 Oct 2002 10:10:38 -0000
@@ -79,10 +79,8 @@
        XPUSHs(pc->extra_args ? pc->extra_args : &PL_sv_undef);
-       perl_call_sv(pc->callback, 0);
+       perl_call_sv(pc->callback, G_DISCARD);
        if (event) { SvREFCNT_dec(event); }
-       SPAGAIN;
-       PUTBACK;
@@ -169,12 +167,11 @@
        PUTBACK ;
-       perl_call_sv(ec->function, 0);
-       SPAGAIN;
-       PUTBACK;
+       perl_call_sv(ec->function, G_DISCARD);
+    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 -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]