[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.
[...]
>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
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
