Re: Glade C code a bad thing? (was: root windows)

[Tristan Van Berkom <tvb gnome org>]

Gus Koppel wrote:
> Olexiy Avramchenko wrote:
>
>
> > Freddie Unpenstein wrote:
> >
> > > That doesn't mean generated code shouldn't be available for those
> > > who consider it the best solution to their particular needs.  Write
> > > a utility that reads in .glade files and outputs code.  Call it from
> > > your Makefile to ensure the source files are kept up to date, and
> > > everyone's happy.
> >
> > Exactly, it's pretty easy to write a 'glade-XML' -> 'C source'
> > translator, if someone needs that.
>
> Yes, pretty easy, indeed. Do you think 100 - 200 lines of Perl would
> suffice or would you need more? I suppose either you have been using
> rather basic design features of Glade only or haven't had a thorough
> look at the generated C code with all its complexity, its structural
> integrity and provision for probably more than hundred different GTK+
> features and distinct GTK+ function calls with several attributes. Not
> to mention the other side, the XML parsing and evaluation.
>
> You'd probably be in the game with 1000 - 2000 lines of Perl (>10 000 if
> counting XML parsing stuff). To most people this is likely not "pretty
> easy". For instance, Jan Karrman probably thought similar when he
> started writing his "html2ps" Perl translation script. Look at the
> latest result: 4500 lines of tight Perl code, unmaintainable, and still
> no support for many HTML features! Regarding text format translations,
> Perl is considered easier than C by most programmers, btw.

    This is the main reason glade-2 has suffered IMO, glade-3
tries to address this problem by reducing special-case code to a
strict minimum, in glade-2; every single widget had special case
code installed for writing source code, glade file output etc...

To generate code based on a glade file shouldnt be too difficult
at all, but yes; there would be alot of code to write; thousands
of lines of no-brainer stuff that just seems like a nightmare to
maintain (actually; this could be alot easier for C source
assuming that you generated code that makes extensive use of
GObject introspection; you might not get away with that when
generating perl or python code, I really dont know).

> Imagine there is an existing Glade-XML --> C source translator. It knows
> perfectly about all features and widget attributes of Glade. (libglade
> from less than 12 months ago still missed support for some Glade
> features!) It is written in C, very fast, stable, fully integrated in
> the Glade UI and well tested. It produces excellent C code which is
> easier to use than libglade and due to its knowledge of GTK+ tricks can
> also serve as programming tutorial reference for GTK+.

Generated C source is definitly not easier to use than libglade;
libglade may have a hard time keeping up with gtk+ widget development,
but really; the way libglade is written today adding support for a
widget is litteraly one line of code (glade_xml_register_widget ()),
you can add it to your code or just bug James to get it in cvs.

> So what would be the intelligent answer to developers who use it and
> benefit from it? "Let's abandon that existing one and rather write a new
> one from scratch if you believe you need it."

I'm not saying that generated source code doesn't have its place;
but as you said yourself, it involves mountains of unmaintainable
monotonous code, so glade-3/libglade is a more generic &
maintainable approach than integrating code generation in the tool
(as was the case with glade-2).

I'm not going to dig up the links, but this definitly has been
discussed before, and as was mentioned earlier in this thread;
people are welcome to write a utility to convert glade files
to source code, we can even discuss making this utility usable
as a plugin to anjuta or directly to glade-3.

Cheers,
                            -Tristan