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 _______________________________________________ Glade-devel maillist - [email protected] http://lists.ximian.com/mailman/listinfo/glade-devel
