[Glade-devel] Draft Proposal: Supporting widgets written in other languages
Tristan Van Berkom
tristan.van.berkom at gmail.com
Mon Oct 9 11:49:50 EDT 2006
Yevgen Muntyan wrote:
> Tristan Van Berkom wrote:
>
>>
>> Thats a good point to consider - maybe its at least possible for a
>> "plugin bridge" to get at the initialized type in the C++/python plugin
>> and syntheticly replicate the type in the GObject type-system in
>> the libgladeui memory space ?
>
>
> Not sure I understand what you mean. Everything is in the same
> process, if you got GType then you're all set. The problem we have here
> is how to get that GType given only its name, and that's there glue is
> needed - python would import corresponding modules, instantiate
> the class, and get its type to glade; or no-real-type module would create
> GType on the fly or something.
I guess I was imaginig a case where it was impossible to have everything
in the same memory space - I guess thats just foolish, I dont know.
[...]
> [snip]
>
>> another question in this vain is - could that be done while
>> maintaining the
>> portability of Glade on all gtk+ supported platforms ?
>
>
> The only non-portable thing here is depending on availablity of dynamic
> modules, but glade already depends on it. GObject system is in glib,
> GModule
> is in glib, the rest is optional, shouldn't be a problem.
What I mean here is - if we go ahead and use an "adapter class" route in
glade,
it would be pointless if glade-gtk.c were to be written in C (in C is
obviously more
convenient to only supply the callbacks needed for a particular class
via the xml
file, otherwise a boiler plate code would have to be written in C for
every single
widget that had anything non-default, any method to override - a
painfull and needless
overhead for the C plugin author).
On the other hand, can we write the gtk+/gnome plugin in python ? and still
be portable on win32 ? ... i.e. will python be portable everywhere gtk+ is ?
Cheers,
-Tristan
More information about the Glade-devel
mailing list