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. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
