Re: Unwrapped gtk+ API

[Torsten Schoenfeld <kaffeetisch gmx de>]

On 12.05.2010 01:22, Quentin Sculo wrote:
> The first patch change the way damage events are blessed, they were
> blessed as Gtk2::Gdk::Event::Damage but it doesn't have the ->area
> method. Damage events are really just expose events. Similar cases in
> Gtk2::Gdk::Event use a common package and are distinguished by using
> ->type. As we can't rename Gtk2::Gdk::Event::Expose, I chose to use it
> as the common package and bless damage event as a
> Gtk2::Gdk::Event::Expose.

Yes, this makes perfect sense.  The current implementation is completely 
broken (Gtk2::Gdk::Event::Damage doesn't inherit from anything), and the 
Gtk2::Gdk::Event::Damage package didn't appear in a stable release yet. 
 So I committed your patch with a slight adjustment and with tests.

> The second patch wrap the offscreen gdkwindow stuff.

Small comments:

â The argument list of gtk2perl_offscreen_coord_translate_marshal is 
indented with a mix of tabs and spaces.  We usually use spaces only for 
these kinds of indentations.  Also, the spacing around parens is not 
consistent in this function.

â Still in gtk2perl_offscreen_coord_translate_marshal, you do

+       XPUSHs (sv_2mortal (newSViv( g_value_get_double (param_values+1) )) );
+       XPUSHs (sv_2mortal (newSViv( g_value_get_double (param_values+2) )) );

This should use newSVnv instead of newSViv.

> I'm wondering if offscreen gdkwindows should be in their own package.

Yeah, me too.  To put offscreen windows into their own package, you 
would alter the gdk_window_new xsub to return an SV directly (using 
newSVGObject_noinc to convert the window to an SV), check for 
gdk_window_get_window_type(window) == GDK_WINDOW_OFFSCREEN and then do 
sv_bless (sv, gv_stashpv ("Gtk2::Gdk::OffscreenWindow", TRUE)).  Then 
you could put the offscreen window methods into the 
Gtk2::Gdk::OffscreenWindow package.  But then again, I'm not sure this 
is worth it.  It adds type safety, but this is not present on the C 
level, and it might constrain us in the future.

> I also added a small comment to gdk_window_geometry_changed, as though
> it can be used with normal gdkwindows, it seems it is only useful for
> offscreen ones.

Makes sense.  But please use proper punctuation in the POD fragments, 
and instead of "gdkwindows", use either just "windows" or something like 
"C<Gtk2::Gdk::Windows>".

> The third patch contains 3 examples for offscreen gdkwindows.
> Two are inspired from the the gtk examples, the reflection one has small
> differences, I significantly expanded the rotation example to make it
> much more fun and generic by using the same matrix for nearly
> everything. (btw a $matrix->copy could be nice, I've used
> $matrix->multiply( Cairo::Matrix->init_identity ) instead.)
> And I've added a third example that simply scale the widget to the size
> of the window.
> I don't know if all 3 examples should be included.

These are great examples, and they should definitely all be included.

> One thing I'm wondering, I've used
> $offscreen->set_user_data($self->window->get_user_data);
> to "attach" the offscreen window to its widget (so that the widget
> receive the expose events). GdkWindows use their user_data to hold a
> reference to its widget. It's the only way I found to do that, and
> though it works fine, maybe there should be a better way.

What does the C code do to achieve that, and what is missing from the 
bindings to make it possible in Perl?

> And by the way, it would be nice if there was a way to get the widget
> of a gdkwindow (to be able to pick a widget with the mouse for
> example), the only way I know of doing that is iterating through all
> the widgets, and it would not work with gdkwindows that are not a
> $widget->window. Also it would make accessing the widget's data from
> the gdkwindow from-embedder/to-embedder callback much cleaner.

I don't think any such API exists in gdk, does it?

So, to wrap up, great work!  Only the tiny changes that I mentioned 
above are left, then this can go in.