Re: libglade vs glade for dialog generation

[Russell Shaw <rjshaw netspace net au>]

Todd Fisher wrote:
> Tristan Van Berkom wrote:
>
> > On Wed, 19 Jan 2005 17:25:59 +0000, Tim Müller <zen18864 zen co uk> 
> > wrote:
> >
> > > On Wednesday 19 January 2005 12:37, Gus Koppel wrote:
> > >
> > > Hi Gus,
> > >
> > > > > Note also that the new generation of glade will not
> > > > > generate code at all.
> > > > >       
> > > >
> > > > Actually, to me that sounds like a threat, which may jeopardize not 
> > > > only
> > > > my but also other people's future work or plans with GTK+!
> > > >     
> >
> > Hmmm, alot can happen when you take a day off ;-)
> >
> >    As some have already mentioned, people are welcome to write code
> > generation scripts/etc based on glade files, the work-load involved in
> > maintaining code-generation as a feature of glade has a major impact
> > on development velocity, which is something to take seriously as specialy
> > in the open source world.
> >
> > The absence of code generation, and other aspects (such as making 
> > extensive use of object introspection) are essential to the survival 
> > of glade-3
> > in the long
> > run IMO.
> >
> > Cheers,
> >                                                            -Tristan
> > _________________________________________
> Seems to me a plugin system for code generation is the way to go.  That 
> way the glade developers don't have to be slowed down by ensuring the 
> code generation is working.  It also means potentially more languages 
> can be supported for code generation.  I would suspect there would be an 
> upfront cost in designing a comprehensive interface for a code 
> generation plugin API, in terms of glade developer cycles.  But once the 
> API is set in stone other projects can be started that focus only on the 
> task of generating code from a .glade file, for whatever language the 
> project desires and of course is supported.   In this way we get the 
> best of both worlds.  I know I learned gtk+ by studying the C code 
> generated by glade, but have found libglade a much faster method for 
> developing applications, with a acceptable amount of overhead, for added 
> benefit in code clarity (just my opinion).

A way of avoiding an api is to make glade generate small and efficient
byte-code instructions for gtk operations such as gtk_button_new() or
box_pack_start() etc, and the instructions are suffixed or prefixed with
the relevant parameters.

A small gtk bytecode interpreter (or widget renderer) can then read these
and construct any complexity of widgets. Whats's more, users programs could
generate this bytecode easily, making dynamically user customizeable menus
and toolbars easy. The bytecode can also be stored on disk, making users changes
persistant. I've been going to do this trick some time anyway.

The bytecodes should be just as easily adaptable to any language.