Re: gtk2-perl / a script to help converting basic functions

Daniel Lacroix <dlacroix erasme org> writes:


With current gtk-perl, when perl destroys a Gtk::Window, it
automatically destroys the "actual" gtk window on the GUI. I like
this feature, it's logical and useful (because it's a toplevel
widget). If we do what you suggest, then we'd need to call
$window->destroy at the user level just before perl destroys the
Gtk::Window. This is another possibility, it's possible, but I
personally don't like it, I prefer it inside gtk2-perl, it's more
clean and more logical for the gtk2-perl users IMHO.

I don't thing that it is unlogical. If the programmer want at a time
close it's window, he will call destroy and not doing $window=undef;
and normally it is the user who close the window by clicking on it and
you don't have to call destroy in your code. You just let it die.

Yes of course at anytime you can call destroy on the window,
before the perl variable is collected. The point was the
opposite: doing a "destroy" call when the perl variable is
collected makes it "automatic". It enables shorter coding style.

There is really no need to keep the perl variable in the same state as
the real pointer un Gtk. If you want to keep your perl variable coherent
why not connect to destroy event of each widget and undef the
corresponding perl variable. This is absolutely not needed.

My point was not to keep the perl variable in the same state as
the gtk variable - see what I've said on the non toplevel

My point is that putting the gtk_destroy call in the DESTROY of
the perl variable seems logical and efficient for GtkWindow, from
the user point of view (the user of gtk-perl). You may want to
keep alive some windows outside their perl scope (decorations
window for example) but for most of them, you want them to
disappear (popups, several different windows of a wizard) so
making them disappear when the perl variable gets destroyed is,
to my eyes, an elegant choice.

Also, this is the same behaviour (from the user side) than in
gtk-perl, which is another argument I think (it eases porting).
Also, don't forget the problem of destructing structs (GdkColor
etc) which we explicetely malloc. We need to free them, gtk won't
do that of course, since it doesn't even know about it except
when these structs are used to pass information to functions.

For struct like GdkColor, you don't have to malloc in C and keep the
pointer. Perhaps that a better solution will be to have a perl hash
table and only convert for the perl href to C struct when using it in C
and free after use. So GdkColor struct will exist only in the C wrapper
function the time of the function. I think that it exist only few case
where we need to malloc and keep a C pointer in perl but have not really
studie Gtk2.

Goran already has done some code for structs, you may propose a
better solution but my proposal's good was that it cleans memory
on goran's implementation choice.

I think what you describe is how it was done with gtk-perl. I
don't know if it's better, especially because it requires "back
and forth" malloc/free each time we use it for a gtk call, which
is probably inefficient.

Guillaume Cottenceau -

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