Re: libglade vs glade for dialog generation

[Russell Shaw <rjshaw netspace net au>]

Gus Koppel wrote:
> 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.

My main aim was for the end user to be able to customize menus, toolbars,
and dialogs. It also means the programmer only has to create the basic
infrastructure, then run the program and create the default toolbars and
dialogs that would be distributed with the program.

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

Bytecodes would be that efficient that i'd doubt the user would notice
any speed loss.

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

The idea was that bytecode can be interpreted in any language, without
the speed loss of xml, and the parser should be much simpler and faster.

I'll try it and see what happens.