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

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



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