[Glade-devel] Re: glade code generation

[christof petig-baender de (Christof Petig)]

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

To support these claims I promise to finish the libglade option in 
glademm this week: generate your program's skeleton by glademm and use 
libglade or generated code by choice.

> 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!)

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

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

> The comment about IDE integration is basically that if the source
> code editing is integrated with the widget editing, then things 
> can work better:
>
>  - You can click on a widget, and edit its callbacks
>  - Source code editing is relatively constrained, because the
>    tool you are using to do it knows about the GUI.

I'm all in favor of IDE integration, but personally I don't need it at 
all. GUI and program code (callbacks) are well separated by glademm 
(IMHO of course).

    Christof (glademm maintainer)