From - Fri Jul 17 15:49:37 1998 X-Mozilla-Status: 0801 FCC: /home/christof/nsmail/Archiv Message-ID: <35AF4CBD.30A7F3F3@wtal.de> Date: Fri, 17 Jul 1998 15:08:14 +0200 From: Christof Petig Organization: Adolf Petig GmbH. & Co. KG X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; uuencode=0; html=0; linewidth=81 X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.1.98 i586) MIME-Version: 1.0 To: Alexis Roda Villalonga CC: Damon Chaplin Subject: Re: glade References: <000001bdb037$d6dc65e0$8f5395c1@default> <35ADAB86.21A7F398@wtal.de> <35ADDA11.2C4E1BE8@fcee.urv.es> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Alexis Roda Villalonga wrote: > Hi Christof, > I'm Alexis and I'll write the module for perl code generation. Damon > proposed two approaches: Hi Alexis, nice to meet you (welcome in the international team). I really enjoy disc= ussing design matters. (And I'm sad to leave for three weeks). > 1) parse glade XML output (as you do for C++, right ?) > 2) write a set of gb_xxx_write_perl_source and a source_perl.[ch] > > The discussion above is for approach (1). I think that code generation > can be handled by a general function parsing XML files wich calls some > "callbacks" functions when language specific tasks need to be > acomplished + some utility functions. That's what I mean with "generic > framework", a library of functions managing common tasks related to cod= e > generation, ideally a generic motor doing all dirty work. It would be > great to hear your ideas about this. I'm also interested on the > structure of your C++ code generator. So here is (as a last post before my holiday) a description of glademm in= ternals: A very simple minded function reads in the glade file in to a Tag tree: class Tag { string name,value; vector child_tags }; You might call glademm with the debugging option (-g) to see this. There's a class Naming which converts widget names to program instances (files/types etc.) Then there's a class File (derived from Naming) which takes care to inclu= de every include file once. and some bookkeeping (delaying output not yet needed).= A class Cxx (=3DC++) accepts the widget tree, adds some internal informat= ion Tags (e.g. whether this Widget includes other widgets) and outputs the whole t= ree as a bunch of files. First it opens Makefile.am, configure.in, main.cc etc. which are widget independant. Then it opens four files (names correspond to the topmost widget name), w= alks the tree node-first (every widget is handled once) and outputs widget creatio= n code. Every widget (writer) supports a set of callback functions to - specify include file(s) - declare the instance variable - construct it (initialize) - add subwidgets - configure the recently created widget ... (sample code, pointer creation/deletion, signal arguments, add-on wi= dget dependancies (e.g. Adjustment, Label)) The four files are: - foo_glade.hh: header file which declares the GUI part (this is not user= editable) - foo_glade.cc: constructors etc for the GUI part (this is not user edita= ble) - foo.hh: declares user-added functions (to derived classes, this is circumventing a genuine C++ restriction) - foo.cc: contains user-added functions Note that glademm files are really OO. Every Container defines it's own c= lass which might contain any user functionality. Viele Gr=FC=DFe Christof PS: CCed this letter to Damon since this first document on glade-- intern= als might be of interest to him. PPS: A last note on why I chose C++ as the programming language for glade= --: - perl was the other candidate but since the design was not a priori clea= r and also changed a lot (this caused unnecessarily bad Cxx and Writer implemen= tation) it would be a too great peril to also learn a new language. With C++ the = amount of work was calculable and I'd not do beginner's mistakes. - I really enjoy an OO design, since it's far easier to maintain. And the= concept of beeing seperate from glade (even when data structures are concerned) m= ight give another choice in future glade revisions. This also gives additional freedom (e.g. preprocessing, widget restructur= ation etc.). Perhaps I'll first implement this Cossy thing via a preprocessing = step (look for common widget structures). - IMHO it is a good choice to implement a converter in the destination la= nguage. Since people using the converter definitely know this language ;-)