Re: Unwrapped gtk+ API



On Thu, 2010-05-13 at 18:50 +0200, Torsten Schoenfeld wrote:
On 13.05.2010 18:25, Quentin Sculo wrote:
gdk_window_set_user_data (widget->window, widget);

I don't think there is a way to get the address of widget in perl.
( no luck with get_pointer )

There is: Glib::Object::get_pointer().  But note that when you call 
get_pointer() on a Gtk2::Widget, you will get Gtk2::Widget::get_pointer().

This works in all of your offscreen examples:

   $offscreen->set_user_data($self->Glib::Object::get_pointer());
indeed, didn't think of that

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?

they use gdk_window_get_user_data, for example gtk_get_event_widget
returns the result of gdk_window_get_user_data
( again, no luck using Glib::Object->new_from_pointer )

I think this does work.  Maybe when you tried it you hit the same 
problem I just described above?  For example, this is true:

$object == Glib::Object->new_from_pointer(
              $object->Glib::Object::get_pointer());

hmm, yes it works, sorry about that, I just did a very quick test before
posting, and it turned out I forgot the "->get_user_data" part :(

still I'm not very comfortable using these functions
(Glib::Object::get_pointer and Glib::Object->new_from_pointer), of
course the whole thing about using a g/set_user_data for storing a
pointer is very ugly.
Maybe creating an API for that in gtk-perl would be nice,
like Gtk2::Gdk::Window->[gs]et_widget, but there's a risk of namespace
collision so I guess that should be done in gtk.
A possibility would be auto-converting a widget to its pointer in
gdk_window_set_user_data, but of course the reverse wouldn't be
possible...

Oh well, at least it's possible, so I guess we can leave it like that.

Quentin




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