Proposal: Supporting widgets written in other languages
Recently in #glade3, me, xjuan, and muntyan were discussing a solution to
the problem of supporting widgets written in other languages.
The solution is somewhat of a detour from our current approach to supporting widgets.
But is elegant in the sense that it uses the Object-Orientated features of GObject to support widgets
written in other languages. It would require an intensive rewrite of portions of glade
and much additional code, so it is of a rather long-term nature (i.e. glade 3.6).
1. Creating libgladeui bindings for other languages
----------------------------------------------------
We allow a /subset/ of libgladeui to be wrapped in other languages. These bindings
will be stored in the glade3 cvs tree. People who are keen to have glade
support their favourite language will be responsible for creating and maintaining
these bindings. On the other hand, since Python is such an integral part of GNOME,
we should at least support and maintain that binding.
So taking Python as an example, the Python libgladeui binding will be responsible
for handling widgets written in Python. This should be easy and straightforward.
At runtime, when starting up, the Python binding glue will always wrap over the
running instance of libgladeui. So the python libgladeui binding will always
represent the running instance of libgladeui. This is the approach that has been
taken in gedit (from what I have researched).
2. Rethinking of how we support widgets in glade
-------------------------------------------------
In the xml catalog files we reference C symbols. We use these symbols to call
the various C functions needed to manipulate a widget properly. I don't think this
approach will scale when we try to support other languages. We need to think of
something different. In any case, I find that referencing C symbols in xml is
somewhat suspect. The catalog files should be independent of implementation language.
A solution would be to convert the "post-create", "set-property", "add-child-function", etc,
functions into virtual methods on a GObject. This way, a GObject widget wrapper will be
able to override these methods as necessary. The beauty of this approach is that these
GObjects can easily be written in languages that have bindings for glib/gtk.
So how would we link a widget defined in a catalog file to it's GObject
wrapper code? We must specify this link in the catalog file, but must make
sure that it is language neutral. A first attempt can be demonstrated by
the example below:
--- foo-widgets.xml ---
<widget-class name="FooBar"
title="Bar"
adaptor-class="org.vgeddes.FooBarAdaptor" />
--- foo-widget-adaptor.c (a GObject wrapper for FooBar widget) ---
/* somehow, we need to make sure the
type is registered at start-up */
glade_adaptor_register (FOO_TYPE_BAR_ADAPTOR, "org.vgeddes.FooBarAdaptor");
The string "org.vgeddes.FooBar" would act as a unique id registered by FooBar's
GObject adaptor class. Not sure how workable or efficient this idea would be
in practice, but at least it illustrates the general route that needs to be taken.
glade3 has a good architectural basis upon which we can support this approach.
the program actually does wrap supported widgets into GObjects (known as GladeWidgets).
However, from what I understand, these objects are only responsible for event-handling
and generic property manipulation. Maybe GladeWidget can be an abstract base class
upon which the "post-create", "set-property", etc, functions are defined as virtual
methods.
Well, thats all. Comments and feedback would be appreciated.
cheers
Vincent