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