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

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 
of derivation to the GType system.

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


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