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

[tristan.van.berkom at gmail.com (Tristan Van Berkom)]

Yevgen Muntyan wrote:

> Vincent Geddes wrote:
>
> > 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 GObject boilerplate. 
> > I think 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.  
> "OO" does no good here. GObject stuff is needed because bindings
> are made to wrap GObject. Or, rather, GObject is preferrable,
> perhaps, at least for python :)
> But "GObject because it's object-oriented" is not that clear - you
> don't need GObject for object-oriented design, you know.

I like the idea of doing both - maybe GladeWidgetClass can be made GObject
and can be derived in some binding like python, or its vfuncs can be 
specified in
the catalog... in which case we might be able to do something fancly 
like generating
a derived type for that  GladeWidgetClass,  effectively offloading the 
complexity
of derivation to the GType system.

If we don't feel like being that fancy we might try having an optional 
adaptor
object provided for that GladeWidgetClass and C libraries would continue
to work the same way.

Cheers,
                                    -Tristan