Re: Glade GUI: changing mechanism

Hash: SHA1

On Tue, Oct 31, 2006 at 10:33:30AM -0500, Tristan Van Berkom wrote:
tomas tuxteam de wrote:
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 

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
Version: GnuPG v1.4.1 (GNU/Linux)


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