[Glade-devel] Re: glade code generation

[e98cuenc free fr (Joaquin Cuenca Abela)]

Hi,

On Thu, 2003-03-06 at 23:02, Christof Petig wrote:
> Hi,
>
> (Sorry, if this looks like crossposting, but all CCs look sensible)
>
> I'm speaking up on behalf of glademm, the (separate) C++ code/project 
> generator for glade. And I like the _choice_ to use generated code.
>
> Owen Taylor wrote:
> > If you generate C code with glade:
> >
> >  - You get C code which isn't related to how you write code by
> >    hand. But if you don't know better, you'll copy anyways.
> >    (Why is this code calling gtk_widget_set_name() and ref'ing
> >    every widget?)
> >
> >  - You get the typical code generation problem that once you
> >    edit it, you risk problems if you generate code again.
> >
> >  - You get something you can't check into source control reliably.
> >
> >  - You go to experienced GTK+ programmers for help, and they
> >    look at you blankly.
>
> I can't speak in favor of the generated C code (I always found the above 
> problems very valid), but for C++ and glademm I found these problems solved.

How do you solve the second problem with glademm?

You generate a file, say foo.cpp, with glademm.  I edit it, change the
glade file, and regenerate the file.  Do you conserve the changes done
to foo.cpp by hand?

Honestly, I don't think that the exact language in which the code is
generated has any impact.

> (Except for the fourth point, you need some glademm knowledge to solve 
> glademm problems/bugs, gtkmm only knowledge might help you but is not 
> always sufficient).
>
> The only reason I was ever tempted to use libglade _internally_ as an 
> optional drop in replacement (_transparently_ to any program code!) was 
> it's good gnome widget support. With C++ it should not make any 
> difference to your program code whether the actual widgets are created 
> by libglade(mm) or by gtkmm (generated code).

exactly like with C.  Please understand that I'm not bashing C++ (as
it's also usually my language of choice), but I don't see any
substantial difference, here.

> > Libglade is a development methology we can support, because it
> > gets used extensively for real apps. There may be full scale
> > apps using generated glade code, but certainly not many of them.
>
> I can name a lot of apps using glademm generated code. There _are_ 
> reasons for generated code:
>
> - a single binary is enough, no need to ship .glade and image files 
> seperately, install them to a known location and find them at runtime.
> - no user can mess up your program's user interface by editing/deleting 
> the .glade/image files (this is clearly a pro and a con!)

I agree that there may be reasons to use generated code (mostly of the
kind of "we don't want a dependency on libxml-2"), but I don't agree
with your reasons.

It's quite rare to find a program that can be installed with just an
executable.  In fact except for trivial programs (and mono executables
when you put everything in the same .exe), you always have a lot of
things to install.  Some .glade files don't make really a difference.

> > > > Makes sense to me; we had
> > >
> > > > Don't use glade to generate code, use libglade!
>
> for C I can't disagree, but I would love to have the option to switch 
> between libglade and generated code (statically linked in widgets) 
> without having to change a single line of the program. Since this is 
> feasible with C++, it should be possible for C, too. Perhaps a nice 
> project for a volunteer? (I don't care about C code)

That feasible in any language.  But that's not the problem.  The problem
is:  How do you deal with changes done by hand in the generated code?

MS deals with this problem adding "please, don't change this code"
comments (and of course, hell opens when you don't follow the advice). 
I guess that I don't have to discuss the problems of that approach...
but in fact, you can't do much better if you generate code.

> A separation of GUI designer and code generator would benefit 
> glade-[123] IMHO. (IIRC glade-3 does take this road)

glade-3 ignores completely the code generator stage.

Cheers,