Re: libglade vs glade for dialog generation

Todd Fisher wrote:
Tristan Van Berkom wrote:

On Wed, 19 Jan 2005 17:25:59 +0000, Tim Müller <zen18864 zen co uk> wrote:

On Wednesday 19 January 2005 12:37, Gus Koppel wrote:

Hi Gus,

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 only
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 of glade-3
in the long
run IMO.


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

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.

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