Re: Glade GUI: changing mechanism

["Olexiy Avramchenko" <aolexiy gmail com>]

On 10/31/06, Carlo Agrusti <carlo-ag libero it> wrote:
> I'll miss it too. This thread is a replica of a similar one spread out a
> couple of years ago; at that time Glade 3 was still far from being short
> to come, and there were more a feeling of a flame war than of a
> constructive discussion.
>
> Now I wish to put on the shields one more argument against suppression
> of code generation features, that is the possibility of using GTK+ based
> apps on embedded systems. Indeed, on modern desktop and laptop systems
> storing a 1 MiB xml file and loading and parsing it at runtime is a
> quite negligible effort, but things changes dramatically on a limited
> resources embedded system.
This was discussed some time ago. The size of XML (and load time) is
not actually a problem here, because .glade file can be transparently
compressed. Libglade loads it just perfectly. The more important
factors for embedded are:
1. Memory consumption. It takes more memory to use libglade/XML.
2. Additional dependencies. You have to keep xml library and libglade
around. (however there was an effort to use for GLibs internal parser
with libglade, if I'm not mistaken).

> Does this means that Glade will not be the most appropriate tool to
> design this class of applications (or that GTK+ will not compete with
> other widget toolkit :-( on embedded systems)?
Having code generation in Glade IMHO is not a good thing for many
reasons. Maybe it's time to make a separate tool for XML->C
conversion?

 Olexiy