[Glade-devel] Draft Proposal: Supporting widgets written in other languages

[tristan.van.berkom at gmail.com (Tristan Van Berkom)]

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