gtk2-perl



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.

If you accept my apologies, maybe you will accept my assistance
to help building it up faster, as far as what I can do? If yes,
here are the things I'd like to ask/discuss/suggest you (against
the 20021014 version):

[*] 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(@_) }


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


[*] 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.


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


[*] 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..?


[*] 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..).

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

  
[*] 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)


[*] 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

and continues to compile the other widgets. But it seems to do
call "gtk_main_quit" so I don't know what's going on - I suspect
it *might* be because the Perl we use is compiled with the
threads enabled; do you see the same behaviour on your machine,
and do you have the threads enabled? (we have MULTIPLICITY
USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT)


Thx,

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



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