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

[Gus Koppel <gtk spamkiller bytechase cx>]

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.

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+.

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."

Thhhhhhank you, sir. This confirms that reinventing the wheel, even with
rough edges, must be more important than i.e. working on end user
applications using GTK+ and Glade.

Sorry if this thread appears to be in the wrong mailing list again.