Re: [Glade-devel] Re: glade code generation



On Wed, 2003-02-26 at 21:24, Tom Ball wrote:
> On Wed, 2003-02-26 at 15:27, Owen Taylor wrote:
> >  Don't use glade to generate code, use libglade!
> 
> I tend to agree, with one important caveat:  code generators are useful
> for creating the callback stubs file(s).  
Yes and no.  They can get you up and running quickly but they can't
support a developer throughout the process.  How many people think of
all the callbacks that they are going ot use the first time they
generate code?  

> 
> I wrote a simple stubs file generator for Java-GNOME's libglade
> support.  It reads a glade XML file and generates a Java source file
> which lists all the event handler callbacks with the correct types and
> necessary import statements.  This utility eliminates a lot of
> boilerplate code entry, and avoids runtime exceptions from missing event
> handlers.  
> 
> I think there's a place for one-shot stubs generators, regardless of
> their level of IDE integration.
>

I wrote a tool called gobject-factory as a way to support my other
development and learn about GObjects.  I quickly found out that trying
to define a GObject in one go was futile when a person basicly has a few
hours to work on projects every week.  After I generate the code once,
gobject-factory become useless and I started using it just to generate
quick stubs and copy & paste the rest.

A better model would be to generate the stubs in an IDE through a wizard
(or in GNOME speek a druid) so that it could integrate itself with the
project and then, through context menus or a simple treeview of the code
structure, allow the developer to add and delete methods, properties.
interfaces, etc.  Since things like GObjects exibit patterns it would be
trivial to keep track of changes and figure out where to generate code. 
If the source does not conform to the pattern the option to generate
extra code is not given.  This would also have the effect of making code
a bit more readable since people who wanted to use this functionality
would have to adhear to the patterns.

I plan to eventualy scrap development on gobject-factory and start
integrating what I have learned into Anjuta2 when I find the time.  The
idea is to be able to keep a steady pace of productivity instead of
having a burst in the beginning and then having it die off because I
forgot to add something I needed at the start.

---
J5  





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