On Tue, Aug 24, 2004 at 23:52:43 -0400, muppet wrote:
>
> On Aug 19, 2004, at 12:32 PM, Jan Hudec wrote:
>
> >This way if the widget itself is not glade-aware, the application
> >still can build it. Downside of this is, that once this module is
> >used, custom widgets implemented in C can no longer be called, because
> >the default widget-building function is not available (not even for C
> >programs :-( ) to be used as a callback.
>
> i don't know quite how far you want to take this, but it should be
> possible to provide a fallback for the default custom widget handler.
It'd be nice. Then the handler could be just installed, because it would
have all the usual functionality.
> there doesn't appear to be any way to fetch the current custom handler
> from libglade, so we'd have to reimplement its functionality. the one
> provided with libglade uses GModule to search for a symbol by name in
> the currently loaded program image. perl's own DynaLoader provides
> tools to do the same thing: dl_find_symbol() and
> dl_find_symbol_anywhere() return the function address in an IV. in
> fact, PDL::CallExt uses this feature to call functions in external
> libraries without having to create xsubs for the first.
> [code...]
> it's a tossup as to whether you want to use DynaLoader or GModule...
> they do the same thing. one benefit of using DynaLoader would be that
> it can look through loaded perl extensions, as well. i successfully
> found the address of a function in libgtk-x11 by using
> DynaLoader::dl_find_symbol_anywhere() after loading Gtk2.
Someone who knows windows should tell us what they do there. But it
seems that DynaLoader supports windows. So we could probably go with it.
Since such handler could do everything the default on can, it could then
go directly in the bindings. And it probably should so we dont have just
another tiny .so.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@xxxxxx>
signature.asc
Description: Digital signature
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
|
