Re: libglade vs glade for dialog generation

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.

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