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

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

Yevgen Muntyan wrote:

> Vincent Geddes wrote:
>
> > I agree that it would be totally unnecessary to have an adaptor for each
> > widget. I am sorry if I made that suggestion somehow.
>
> No you did not. I just wanted to make sure that "wast amount" of
> everything and what I heard on irc wasn't what I thought it was :)
> Sorry for being harsh, it wasn't meant to offend you or something.
>
> > By using virtual
> > methods and generalization, we would not need to write an adaptor for
> > each and every widget. For example, a GtkBin widget could simply use a
> > GtkContainerAdaptor. This same GtkContainerAdaptor would be a subclass
> > of GtkWidgetAdaptor, and so on...
> >
> > This object orientated approach would ensure that no code would need to
> > be duplicated or written unneccessarily. Hopefully this would ease your
> > concerns?
> >  
> "no code would need to be duplicated or written unneccessarily"
> sounds great to me :)
> I can't comment on real technical stuff like GtkWidgetAdaptor
> and GtkContainerAdaptor vs. AnyThingYouCanImagine, because,
> as I said, I don't know what exactly is needed. I do agree that
> something is needed :)
>
> > This "Adaptor" idea is really just a refactoring of the code in
> > `glade-gtk.c' into a more object-orientated form. I don't see how else
> > we can support multiple languages in sane way.
> >  
> When I was talking about python and GObject, I missed an
> important detail: pygtk until 2.10 did not quite support deep
> derivation of GObject. Namely, if you had class CClass in C,
> then subclassed it in python with PythonClass, and then
> subclassed it again with PythonChild, it was impossible to
> call CClass virtual methods of PythonChild instance. So,
> for instance if we simply require binding to provide GType,
> python users (with pygtk < 2.10) won't be able to subclass
> PythonBindingThing. E.g. GtkContainerAdaptor could not
> be written in python (as a subclass of GtkWidgetAdaptor
> written in python).
> Next, if I recall correctly my fightings with Murray Cumming,
> C++ does not care about other languages at all, and you can't
> create an instance of C++ type in C code (namely, g_object_new
> won't work quite right). I might be wrong, but I believe it's very
> possible in other languages too.
> So, GObject is good, and we should use it when possible, but we
> need to check bindings to see what they can. Like, in this example,
> it might be not enough to have GType, maybe we need a virtual
> method on Loader (or Catalog or Plugin, whatever) which would
> create an instance given its type name. We can assume that glade
> module is written in C, and we can assume that the module can
> call any native code and work with native types and stuff; but we
> can't assume the module will provide a real bridge from glade to
> binding (it will, in one way, but that way is opposite to what glade
> needs :) ).


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 ?

My thoughts on this thread so far are:
   o Using an "adapter class" would definitly help by deffering all the
      inheritance mechanisms in glade-widget-class/glade-property-class back
      into gtk+/gobject

   o Using an adapter class in the current codebase would probably involve
      using an adapter for every widget that requires at least one 
callback or
      customized properties, it would in turn make as much sence to use 
adapter
      classes for properties as well as widgets... while this might be a 
clean design,
      in C it translates to _alot_ of unnescisary boiler plate code - so 
if the plugin were
      to be written in C - this would be a little annoying (even if you 
only need to
      override a single vfunc or constant in the parent class - you need 
to initialize
      the type manually).

   o Maybe this approach works nicely in python, I think gazpacho uses 
this adapter
      class technique - so, if it would benefit everyone - could the 
gtk+/gnome library
      plugins be written in python - even if the GTypes come from a C 
library ?
      another question in this vain is - could that be done while 
maintaining the
      portability of Glade on all gtk+ supported platforms ?

Cheers,
                                        -Tristan