Re: Glade GUI: changing mechanism

[tomas tuxteam de]

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

On Tue, Oct 31, 2006 at 10:33:30AM -0500, Tristan Van Berkom wrote:
> tomas tuxteam de wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> [...]

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 
>       consumption.

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.

Amen.

Regards
- -- tomÃs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFSyTBBcgs9XrR2kYRAksBAJ99HPRgVfsRoQoHuFLPjLc160J6IwCeLriA
2a8raQv09EjTItMx4igekQk=
=G7Iy
-----END PGP SIGNATURE-----