Re: RE : Re: glade code generation

Hello all,

I am the author of gobject-factory a gobject code generator.  It has
been mentioned to me by Biswapesh of Anjuta fame that a new project I am
going to embark on has the potential to help out in the code generation
glade area.  Basicly gobject-factory has become useless to me for the
same reasons that code generation in Glade is bad.  Basicly I have to
think of everything I want up front or trash my hand written code later
because I needed to generate the code again.  Basicly I am going to
integrate what I learned from gobject-factory into an Anjuta 2 plugin
that allows a person to add and remove methods, properties, and signals
on the fly instead of all at once.  Since GObjects have the same
patterns as GtkObjects, using it to keep track of callbacks and
essentialy glue Glade and Anjuta would be trivial.  I am not starting
the project right away since gobject-factory is a utility to help with
another project that I want to get a little further in before I start
and I am also waiting for SourceBase (source code tagging) to get into
Anjuta.  It is something to look out for as a potential way to solve the
code generation problems. Some comments on the issues inline bellow.   

On Sat, 2003-03-08 at 09:26, Joaquin Cuenca Abela wrote:
> Murray wrote:
> >
> > > but in fact, you can't do much better if you generate code.
> > 
> > C++ has the concept of inheritance. glademm generates only 
> > base classes.
> > User-written code is in user-written derived classes.
> 
> That's irrelevant.  The question is: what happens when the user edits
> code that he shouldn't edit and later it regenerates this code?
An incremental code generator would only generate new code as needed.
When a user edits code the generator will learn the changes.  The
generator will only edit existing code if the user then goes and asks
for the generator to edit it.

For instance my gobject generator will be generating signals which need
to be entered in three places in the code - the Gobject's class
structure, the signals enumeration and registered somewhere in the
implementation file, usualy in the init method.  When a user generates a
signal code is placed in these three locations and the generator has
some way of displaying that the signal exists and can be edited by the
generator.  Say the user goes and edits the signal all that is realy
significant to the generator is the signals name so the edited code will
not affect the generator unless the name is changed.  Say the name is
changed in one place, the generator will display that the signal is now
broken because some of the elements that make up the signal pattern are
missing (which would be an error in the code anyway).  When the user
goes and changes the name in all three locations the pattern is again
complete and the code generator registers the new signal name.  The same
would happen if the user created a whole new signal by hand.  The user
would only be allowed to use the code generator on signals whoes
patterns are not broken.  Now what happens if the user slightly edits
the signals registration code and then uses the generator to edit the
signal?  Two things could happen, the generator could be dumb and just
warn the user that the code seems to have been edited by hand and if
they continue it might clobber their changes.  Or the generator could be
smart enough to understand what changes effect what and only do changes
if they will not effect the code (such as changing the name of the
signal which can be done safely even if the user has changed some of the
parameters when regestering the signal with the GObject).  Of corse at
some point a programmer has to resposible for their own code. 


> Two different places to put the same info is one too much, and as the
> task of extract the information from a .glade file is several orders of
> magnitude easier than extracting it from the code, .glade files should
> be used.
Nothing extranious should go in .glade files.  They should be lean and
mean. 

> I still see useful (for those who don't like an extra dependency) a
> utility that converts a .glade file to [pick you language] code,
> hopefully one that, with enough makefile's magic can do the conversion
> automatically at compilation time (kind of like the RC compiler on
> windows).
Code generators dumping out code at compile time is bad.  A user should
be able to inspect the code and make changes by hand.  At that point you
have to ask yourself why not use libglade.

> But that's out of glade's scope.

But not out of Anjuta's as was pointed out to me.  As I devlop my
project I will keep in mind these other concerns and try to program
around a more flexable design.

--
J5

_______________________________________________
Glade-devel maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/glade-devel