-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Nov 08, 2006 at 07:35:19PM -0500, Tristan Van Berkom wrote: > [EMAIL PROTECTED] wrote: > > >Sorry for not answering sooner. Lots in my inbox lately (literally ;) > > > > > > > No problem, I went out of town for 4 days and came home a whole > lot of mail too.
Ah. Again late. Sorry again. > >OK, let me dream aloud (it'll have far less weight than actually > >contributing code). What libglade provides is a "glade-xml" interpreter, > >for some language "glade-xml". What is the difference to a "glade-xml" > >compiler? Can't both of them be generated from the same source? > > > > > That is a little inacurate, libglade interprets the glade file > directly and code generators use the source - the source is > the glade file - the source of the glade file is the internal data > structures of the glade designer program (remember that historicly > the glade file was the internal format of the glade tool, used > as you mention below as an "abstract representation" of the gtk widget > heirarchy - the glade tool would then output code based on its loaded > state)... so in the end - generating code is only an extra step. My rambling above was put in misleading terms. I was not talking about the source of a libglade application, but about the source of the "glade compiler" or the "glade interpreter" itself: the meta-source, if you want. [...] > Lets not sound misleading here... gtk+-2.12 should be featuring > the capacity to load itself from a glade file (or maybe a very very > similar format) - it will generally have the same structure and it > will be xml, only GMarkup will be used to parse that xml, not > libxml2. So it's a stripped-down XML. I am always afraid that all the issues XML has as a data description language (e.g. brain-damaged escaping within attribute values, incredibly complex whitespace handling at tag boundaries, two-dimensional hierarchy [is something to be expressed as attribute or as sub-tag?] -- I could go on) obfuscate the design of the abstract model. And there is evidence for my fear: look at the incredible complexity the XML consortia are producing. Would you know at a glance whether the models behind the XPath search specifications are compatible with DOM? I can't. To me, this is a clear case of decommoditized protocol, a reason to stay as far away as possible. XML as an input/output format (among others): yes. XML as the canonical format to design and understand my apps: no thanks. Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFWa+LBcgs9XrR2kYRAvJhAJ4msjf/PsvSeGAyNBaA3KjUuj1YMwCfQVaA 26Q2S/pKfvVPVTm19AiEPW0= =TcM3 -----END PGP SIGNATURE----- _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
