Re: Glade GUI: changing mechanism
- From: tomas tuxteam de
- To: Tristan Van Berkom <tvb gnome org>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: Glade GUI: changing mechanism
- Date: Fri, 3 Nov 2006 11:15:13 +0000
-----BEGIN PGP SIGNED MESSAGE-----
On Tue, Oct 31, 2006 at 10:33:30AM -0500, Tristan Van Berkom wrote:
tomas tuxteam de wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Sorry for not answering sooner. Lots in my inbox lately (literally ;)
This thread is getting a little redundant [...]
yes, the thread got (thematically) a bit out of control. I still thought
it to be interesting.
[...] this ended up in my overly-rude comment about cooperating with
FOSS developers (sorry you all had to hear that).
FWIW, I didn't perceive your postings as "rude" (by a far stretch). On
the contrary, I do appreciate your contributions in this mailing list,
and especially on this issue. We may have different viewpoints, but I'm
still eager to learn from yours -- may be my sometimes blunt style
doesn't carry this across. Sorry for that.
Now if I can settle any misgivings I'll try here.
a.) People need to understand that Glade developers didnt ever
tell the universe that generated code from glade files cannot
be done - niether did we obfuscate the glade file in a way
to make it difficult for people to generate code from - we simply
externalized this feature so that we can focus on more important
things - if code generators are to exist - they should take glade
xml data as input.
This makes perfect sense. I will still (from time to time) air my
dislike towards XML. When this gets annoying, I hope someone slaps at me
That above is pretty much the official take - now if you'll
indulge me - I'd be happy to argue the irrelevence and futility
of using generated code to the death, not with my Glade hat on
but just from one developer to another.
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?
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?).
b.) The point Olexiy raised about embedded is precise, there is no
real issue about the size of the glade file on modern tiny systems,
its more the memory footprint that is dramatically increased
by dragging in libxml2. What the PalmSource people did about this
(not sure if they got to it, but if they did - I'm sure they are
ready to share it) - is they created a libglade equivalent that
parses a binary data file, and a tool that creates the binary based
on a glade file, thus eliminating the libxml2 hit on memory
Yep. See above. And they might have an easier job if the widget
definition language were defined in abstract terms instead of being at
the mercy of xml quirks and kinks.
c.) Where we are going - there are no roads (I just wanted to say that),
the point here is that - in gtk+-2.12, assuming everything goes as
planned, we will have glade file parsing /native/ to gtk+ (using
GMarkup instead of libxml2). There will be no more libxml2 woes and
even less reason to use generated code.
- -- tomÃs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
-----END PGP SIGNATURE-----
] [Thread Prev