Re: gtk2-perl


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.

Everyone can use the project page at:
for bug report, feature request, patches etc.

Discussion is best held here on the gtk-perl mailing list.

here are the things I'd like to ask/discuss/suggest you (against
the 20021014 version):

OK, let's see:

[*] For porting applications, I've noticed the following few

- Gtk2::GSignal->connect($widget, ..)
  instead of


  why is this? I understand it's closer to the Gtk+ functions but
  it would also be important to ease porting from gtk-perl to
  gtk2-perl, I think (and the second form is shorter). Maybe you
  would accept adding the following to to provide
  the second form of call as well:

use Gtk2::GSignal;
sub signal_connect { Gtk2::GSignal->connect(@_) }

this was suggested by Dermot too (in private mail).
added to CVS

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

  This is because you favor cleanness over compatibility with
  gtk-perl I suppose? Though I think there was a real good point
  in the way it was handled with gtk-perl: when you used a wrong
  value, you had a very clear error message:

invalid GtkWindowType value topleel, expecting: toplevel, dialog, popup

  Now we have:

Argument "Gtk2::Window::TOPLEEL" isn't numeric in subroutine entry at

  Or if using Gtk2::Window->TOPLEEL:

Can't locate auto/Gtk2/Window/ in @INC (@INC contains: .....)

  Do you think we could achieve a better error reporting on that
  topic? With such "type checking" I think maybe the original
  idea was better (and it's shorter).

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.

I haven't look too much on the old code,
so backwards compatability has not been 
a goal so far. But that could change if
edxamples and patches are contibuted.

[*] What's your feeling about the .defs serving for
auto-generating a part of the code? It seems that perl-gtk was
using it, python-gtk also is using it... and it seems to be a
great deal of code (I've yet to understand better the part of
code which is autogenerated, and how is decided that part - but
mostly it seems to be structs and helper defines to not pollute
the XS code with casts etc). I though I remembered you already
expressed your feelings about it (negative feelings IIRC?) but I
can't find it in the archives of the mailing-list :-(. Please
direct me to the archive if my memory was right but my searching
abilities too poor.

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.

Sometimes the wrapping means you have to understand the
function and its arguments. I am currently wrestling with
one such case explaining to slow down in updates the last 
few days. I have yet to see an autogenerator that has that
kind of intelligence.

[*] has "use Gtk2::Gdk::Window" but the 20021013 and
20021014 tarballs don't have any Gdk subdir in Gtk2..?

use CVS. I will remove the snapshots any day now.

[*] talking about Gdk, is auto-generated? it seems
not, or I didn't find the script to generate it.. it seems to
contain many enum-like stuff, it would be probably safer and
better for the future to auto-generate it..?

No it is not,
for enum autogeneration maybe would be acceptable.

[*] I've noticed that in GSignal.c you use the following to call
a perl function:

      perl_call_sv(pc->callback, 0);

According to perlguts, this is deprecated since 5.6.0 and should
be replaced by "call_sv"? but maybe you want to keep it for
compatibility (though 5.6.0 is already pretty old..).

It works as is on 5.6.1 and 5.8 so I suggest leaving it as is
for now. Someone suggested only 5.8.x is usable because of
UTF issues with earlier releases, but most distributions (and
most users) have yet to upgrade to 5.8 so we might not want to
rush things.
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.

[*] Also, how do you use perl-Inline for developing/debugging?
Each compilation error is problematic since one needs to manually
cat the file _Inline/build/Gtk2/whatever/out.make. Additionally,
it seems slower than normal XS compilation (I don't have actual
figures though) (hum.. is there any real good of using
perl-Inline with separate C files? setting up the XS interfaces
is not at all the longest part of XS development, so I don't see
quite clearly anymore your interest for perl-Inline except using
a bleeding edge new technology ;p)

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.
Besides Inline is not bleeding edge anymore, 
it will be a standard module in perl 5.10.

[*] When clicking on the button of "", the
application doesn't quit; it prints:

( Gtk-CRITICAL **: file ../../gtk/gtkmain.c: line 994 (gtk_main_quit): assertion 
`main_loops != NULL' failed

That script is not written by me :-)
I will apply the patch you sent to the list.

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.

best regards,

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