Re: libglade vs glade for dialog generation
- From: Russell Shaw <rjshaw netspace net au>
- Cc: gtk-app-devel-list gnome org
- Subject: Re: libglade vs glade for dialog generation
- Date: Fri, 21 Jan 2005 14:39:38 +1100
Todd Fisher wrote:
Tristan Van Berkom wrote:
On Wed, 19 Jan 2005 17:25:59 +0000, Tim Müller <zen18864 zen co uk>
Seems to me a plugin system for code generation is the way to go. That
way the glade developers don't have to be slowed down by ensuring the
code generation is working. It also means potentially more languages
can be supported for code generation. I would suspect there would be an
upfront cost in designing a comprehensive interface for a code
generation plugin API, in terms of glade developer cycles. But once the
API is set in stone other projects can be started that focus only on the
task of generating code from a .glade file, for whatever language the
project desires and of course is supported. In this way we get the
best of both worlds. I know I learned gtk+ by studying the C code
generated by glade, but have found libglade a much faster method for
developing applications, with a acceptable amount of overhead, for added
benefit in code clarity (just my opinion).
On Wednesday 19 January 2005 12:37, Gus Koppel wrote:
Note also that the new generation of glade will not
generate code at all.
Actually, to me that sounds like a threat, which may jeopardize not
my but also other people's future work or plans with GTK+!
Hmmm, alot can happen when you take a day off ;-)
As some have already mentioned, people are welcome to write code
generation scripts/etc based on glade files, the work-load involved in
maintaining code-generation as a feature of glade has a major impact
on development velocity, which is something to take seriously as specialy
in the open source world.
The absence of code generation, and other aspects (such as making
extensive use of object introspection) are essential to the survival
in the long
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.
] [Thread Prev