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 <christof.petig@wtal.de>
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 <arv@astor.urv.es>
CC: Damon Chaplin <DAChaplin@msn.com>
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<Tag> 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 ;-)


