Re: gtk2-perl

[goran kirra net]

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.

Everyone can use the project page at:
http://sourceforge.net/projects/gtk2-perl/
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
> differences:
>
> - Gtk2::GSignal->connect($widget, ..)
>   
>   instead of
>
>   $widget->signal_connect(...)
>
>   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 Gtk2::Object.pm 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/TOPLEEL.al 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.
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.

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.

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.

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.

> [*] container.pl 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 Gtk2::Gdk.pm 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
> 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.

> [*] 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 "compile-widgets.pl", the
> application doesn't quit; it prints:
>
> (compile-widgets.pl:30122): 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,
-- 
Göran