Re: [gtk-list] Re: Glade/Gtk-- design proposals (longish)

[Christof Petig <christof petig wtal de>]

Guillaume Laurent wrote:

> Christof Petig <christof.petig@wtal.de> writes:
>
> > glade2cxx might be or not be a seperate program: (+ pro / - con)
> > + a decent C++ class hirarchy (with STL) can be used to parse the glade
> > file and produce output.
> > + Flexible, up to date (STL), easy to extend,
>
> Don't count on the STL too much. At this time gtk-- is still supposed
> to be compilable with gcc 2.7.2.

I would never dare to begin a NEW project with avoidance of the STL. The
STL is a big step ahead and programming your own containers is not a sensible
task, though an STL compatible vector would be possible.

> > - code duplication (the methods to read XML and write C code are also in
> > gbfoo.c). They need adaption, though they should not share too much
> > (classes are a different concept).
>
> Is the parsing code actually written, or is it lex/yacc generated ?
> pccts would be a good choice I think. Its C++ support is much better
> than lex/yacc's.

AFAIK, the XML parser is about 70 lines of C code, the tags are interpreted by
the gbwidgets.Duplicating/reimplementing this is no problem.

> > + small, pure C++ design
>
> When writing gtk-- bindings, one of the hardest things is to determine
> what should be rewriten in C++ (usually very little, but the
> temptation is usually great) and what should be left as calls to C
> functions... The overall idea is to write as little code as possible.

Does my example cover this topic? I don't understand exactly what you are
speaking about.

> > I tend to make it a seperate beast.
>
> I sympathize with your feelings toward C++ (myself preferring C++ over
> C any day), and I've never seen glade's code (so I probably should
> shut up :-), but I'd still advise you to think carefully about what
> you can reuse.

Glade doesn't have code creation yet :-(.

There was a proposal of an plugin API. This sounds good and perhaps is the way
we should go.

Regards
   Christof