Re: Unwrapped gtk+ API

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

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

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