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

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

"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 
      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 ?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]