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

[vgeddes at metroweb.co.za (Vincent Geddes)]

On Mon, 2006-10-09 at 11:49 -0400, Tristan Van Berkom wrote:
> 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).

The GObject boilerplate problem is a definitely a drawback of this
design. However I think the benefits of the design greatly outweigh the
negatives. I think we can come up with creative solutions to minimise
the need to unnecessarily write boilerplate.  

We can help C plugin authors by providing a simple, no-frills
script that generates GObject boilerplate. The script will take a few
parameters and will output GObject boilerplate. Similarly, the gedit
developers have a script that creates a GObject plugin skeleton for
their plugin architecture.

We could also have some adaptors handle common widgets. For example, a
GladeDialogAdapter could handle a GtkColorSelection, GtkFileChooser,
etc, by using case programming. By 'case' I mean that GladeDialogAdapter
will change it's behaviour depending on what type of widget it is
adapting. While this is not considered "good" OO, it does balance the
need for an object-orientated architecture with the need for fast and
efficient programming. 

regards

Vincent