Re: libglade vs glade for dialog generation

[Gus Koppel <gtk spamkiller bytechase cx>]

Russell Shaw wrote:

> A way of avoiding an api is to make glade generate small and efficient
> byte-code instructions for gtk operations such as gtk_button_new() or
> box_pack_start() etc, and the instructions are suffixed or prefixed
> with the relevant parameters.
>
> A small gtk bytecode interpreter (or widget renderer) can then read
> these and construct any complexity of widgets. Whats's more, users
> programs could generate this bytecode easily, making dynamically user
> customizeable menus and toolbars easy. The bytecode can also be stored
> on disk, making users changes persistant. I've been going to do this
> trick some time anyway.
>
> The bytecodes should be just as easily adaptable to any language.

While bytecode sounds good at the first moment, I don't think it would
make much sense. It would certainly require a large effort to implement
such a bytecode writer and interpreter.

The Glade generated C code could be considered the source for bytecode.
The C compiler converts source statements into machine opcodes, which
can be considered a sort of bytecode as well, although not machine-
independent, but bound to the underlying CPU architecture. The result is
basically as small and compact as i.e. Java bytecode would be. The
advantage of this sort of "bytecode" is, that it doesn't need any extra
software at runtime nor any sort of further interpretation. So speed and
efficency are at their maximum.

Actually, the XML files fulfill some characteristics of bytecode
(although they're rather "plaintext wordcode") as well. They 1. contain
unambiguous instructions and orders for what and how to do, 2. are
platform-independent, 3. need to be interpreted by additional software,
4. hence are slower than native execution. Same as with Java, it's the
additional overhead of runtime interpretation (extra software, extra
memory requirements, lower speed) that is the main problem.

While logically and technically possible, I don't think another layer of
bytecode (between XML and native machine language) would be worth any
efforts. The XML "code" provides all information to create any form of
final code, i.e. C sources. The desire by some (including me) is just to
keep this existing maximum performance functionality.