Re: glade code generation

[Bill Haneman <bill haneman sun com>]

On Thu, 2003-02-27 at 10:55, Mark McLoughlin wrote:
> > > 
> > > That would rock. I am all for it.
> > 
> > I don't think it would be a good idea.
> 
> 	But why don't you think it would be a good idea ... ?

Removing code generation would regress some projects.  Granted, we want
them to use libglade for a number of reasons - but this would still be
pretty unfriendly IMO unless we took a couple of other steps too
(below).  Also, people _do_ like and expect code generation sometimes. 
Also, the (available) glade tutorials pointed to on the gnome.org site
all use code generation, ugh.  Lastly, there is one aspect of the
current code generation which is useful; the auto-creation of the
handler stubs in callbacks.c; I can't see a good reason for disallowing
that; I think it's the interface.c and main.c stuff we want to get away
from.

Instead of just papering over the problem by hiding the code generation
feature as I suggested initially, I think there's a better option:

* make sure James' libglade overview information is linked to the GNOME
developer site (preferably under d.g.o's Architecture and Design
section); ideally we'd amplify James' one-page intro to libglade a bit
too: http://www.daa.com.au/~james/software/libglade/
We could use this as the jumping-off point leading developers to the
libglade reference manual, so that GLADE+libglade is made immediately
visible to new developers as a preferred technique.

* retain source code generation, but make main.c look like James'
"minimalist libglade program", i.e. main() calls glade_init(),
glade_xml_new(), and glade_xml_signal_autoconnect().  Retain
callbacks.[ch] as just a bunch of stubs that the developer can use as a
template.

This would have these advantages:

* a glade project would create a buildable, runnable standalone UI shell
	just as it now can;

* the code generated would actually be a good, rather than bad,
	influence if used for copying by novice gnome programmers;

* developers would have the small convenience of getting pregenerated
	stubs instead of having to work out names for all the widget
	handlers in advance of running glade.

* developers who have been using glade in code-generation mode would get
	a gentle rather than brutal nudge down the libglade path.

Of course there's nothing about creating callbacks that anybody with a
text editor can't do in a few minutes, but it is a bother to either have
to work out the handlers in advance (defeating some of the purposes of
interactive GUI design), or to read them off the glade XML file or glade
UI and paste them into a separate text editor.  The handler stub
creation also helps avoid simple errors and is generally a good
orientation tool for new GNOME developers as well.

So I think that by making GLADE's generated code use libglade we can
accomplish the goal of this thread without removing code generation's
modest benefits, and without needing to get too deep into the glade code
itself. 

- Bill

> 
> >   Surely there is some other way
> > of making the code generation feature less visible?
> 
> 	To what end ?
> 
> Good Luck,
> Mark.
-- 
Bill Haneman <bill haneman sun com>

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers