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 ucw cz>
Attachment:
signature.asc
Description: Digital signature