[Glade-devel] Re: glade code generation

[christof petig-baender de (Christof Petig)]

[cc list trimmed somewhat, will remove gnome-hackers at next reply]

Joaquin Cuenca Abela wrote:
> How do you solve the second problem with glademm?

[second problem is: avoid user overwriting generated code, avoid to 
overwrite user written code]

there are two separate classes, and four (or six) files for each widget 
tree (toplevel window):

- foo_glade.hh: UI class declaration, never edit, overwritten [contains 
the declaration of user visible widget pointers and the pure virtual 
callbacks]. Informative to look into when you write the actual program.

- foo_glade.cc: UI class methods, never edit, overwritten [construction 
and customization of the widgets, callback connection] Usually nobody 
ever looks into this file (unless out of curiosity).

- foo.hh: User class, derived from UI class, needs to override every 
connected signal handler to be instantiable, glademm outputs a first 
empty skeleton but never touches this file again (it emits a foo.hh_new 
which you can copy new callback declarations from). If there are no 
callbacks, this class can be empty (or even missing)

- foo.cc: normally contains the flesh (definition) of the callbacks, the 
c(onstruct)tor and the d(estruc)tor. Of course the physical location 
(which file the definitions are in) is not relevant, arrange them 
according to your taste. My ctors usually fill the window with content 
(from a database) and (typically) take a number of parameters to control 
their behaviour.

> 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?

see above. The code is well separated.

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

It does not have to have impact. But since C++ programs tend to organize 
differently (class inheritance) from C (collection of functions) the 
generated code looks totally different for glade and glademm.

> > 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.

Due to my effort yesterday, glademm now offers the option (pupal state) 
to use generated code and libglade as a drop in replacement (no code 
change). I don't know of any effort to make glade generated code and 
libglade API compatible, but it would benefit.
[Stop, I'd enjoy such a project. I'm not saying C++ is better, I'm 
saying: I did it for C++, who want's to do it for C?]

> 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.

Agreed. But there are such programs (single binaries), it gets more 
likely if you depend on external things (like a database infrastructure, 
available binaries etc.). Personally I dislike to depend on external 
files (and how to find them at run time) unless necessary (you know: 
make sure to install them to a _proper_ place, binary will not work 
until support files are installed to target location, yuck). A binary is 
easy to copy around once it's self containing. [I have no problem to 
depend on shared libraries!]

> 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.

Well, I don't open the gates of hell - glademm simply overwrites the 
changes in the "changes will be lost" marked files. Usually nobody needs 
to change them (glademm bugs put aside).

Yours
    Christof

PS: Am I correct to assume you are involved with glade-3?