Re: Glade GUI: changing mechanism



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.

[...]

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.

Or more to the point: this "glade-xml" language is a concrete syntax for
an abstract "widget definition language". I'd rather prefer to see an
abstract model first and several concrete syntaxes, perhaps a very
compact binary form among them. This seems to be what you talk about in
(c) down there, envisioned for gtk+-2.12, right? (Or is this just going
to be a stripped-down xml syntax with an ad-hoc parser?).
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.

Cheers,
                                 -Tristan




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]