Re: [Glade-devel] Re: glade code generation



[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]