Re: Glade GUI: changing mechanism

[tomas tuxteam de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Nov 08, 2006 at 07:35:19PM -0500, Tristan Van Berkom wrote:
> tomas tuxteam de 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-----