Re: [Glade-devel] Re: glade code generation
- From: Christof Petig <christof petig-baender de>
- To: Joaquin Cuenca Abela <e98cuenc free fr>
- Cc: gnome-hackers gnome org, glade-devel ximian com, glademm-list gnome org
- Subject: Re: [Glade-devel] Re: glade code generation
- Date: Sun, 09 Mar 2003 01:46:48 +0100
[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?
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]