RE: [gtk-list] RE: Code generation for GTK+ apps

["O'CONNOR, Steve" <SOCONNOR baea com au>]

have a look at http://www.iweb.net.au/~steveoc/gnuera.html

This is an ambitious project to do a high-end case tool. I will have a
simple screen editor in there, but the purpose of this is more to
describe the screen in terms of the database and overall function of the
screen rather than the nitty gritty details.

On the generation phase, a database schema (create_database.sql) is
created, a number of utility functions (c code) are created, and I think
with the screen code, I will either generate c code, or a higher level
XML type spec for the screen. It was a good design move on (your ?) part
to use such a format for the native storage in Glade.

Gnuera and Glade should fit in well together for doing database apps.

- Do a high level requirements spec, test cases, etc
- Model the underlying database using an E-R editor
- Draw a navigation diagram for the whole application
- Gnuera to generate a standard layout for a screen depending on it's
function, and then invoke Glade to fine tune the screen.

What do you think ?

> -----Original Message-----
> From:	Damon Chaplin [SMTP:DAChaplin@email.msn.com]
> Sent:	Friday, 21 August 1998 08:53
> To:	gtk-list@redhat.com
> Subject:	[gtk-list] RE: Code generation for GTK+ apps
> 
> 
> > On the subject of code generation from higher level tools, the
> problem
> > always arises where you want to be able to add tweaks to the
> generated
> > code, but not have them clobbered when the higher level tool
> regenerates
> > the code. Some high level tools try to solve this by allowing the
> tweaks
> > to be defined up at the IDE layer, but the end result is usually a
> > restricted development environment and a bloated binary (vis Visual
> > Basic, 4GL's, etc). There is simply no substitute for loading up raw
> > source code in vi or emacs and doing what has to be done.
> 
> When Glade's C source generator is finished, I hope it will be fairly
> easy
> to tweak the code. The generator will output 2 types of files:
> 
>  - files which contain functions to create user interface components
>    (windows/dialogs). These files should not be touched by the
> developer.
>    The developer calls these functions from another source
>    file (which Glade doesn't touch), and can tweak the created
> component to
>    their hearts desire, before showing it. In fact, to use
> lists/clists etc.
>    the developer will have to add code here to insert the list
> elements,
> since
>    Glade doesn't support them and they probably need to be created
> dynamically
>    anyway.
> 
>  - files which contain signal handler prototypes, which the developer
> fills
> in.
>    If the interface is later updated, and the source regenerated,
> Glade will
> only
>    append to this file. It will add any new, or updated, signal
> handler
> prototypes.
>    So none of the developer's code will get clobbered. But the
> developer is
>    responsible for clearing out any old signal handlers which are no
> longer
> used.
> 
> I hope this will be enough for most cases.
> 
> Damon
> 
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com <
> /dev/null