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

[Guillaume Cottenceau <gc mandrakesoft com>]

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
widgets.

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 - http://people.mandrakesoft.com/~gc/