Re: libglade vs glade for dialog generation

[Gus Koppel <gtk spamkiller bytechase cx>]

Tristan Van Berkom wrote:

> > - have higher RAM conumption at application execution time
>
> Only at startup time afaik; Unless your talking about the actual code
> segments in memory.

I'm talking about code segments of additionally loaded libraries and
data segments of the loaded XML file and internal processing objects.
None of them apply to hardcoded GUI definitions, except for a somewhat
larger binary of the main program itself, of course.

> I'm not an expert on OS's but doesn't the OS usualy handle that
> nicely?

Posix OSses usually don't.

> > - have lower application execution speed (dialog open delays)
>
> Why would you create your dialog from the xml more than once in the 
> application ?
> Do you have such a complex dialog that its inacceptable to just hide
> and keep in memory ?

It's not only the complexity of a single dialog but also a greater
number of dialogs at all. I consider it unacceptable indeed to keep,
say, 10 or 20 dialogs prepared but hidden in memory. My steps to open a
dialog using libglade looked basically like this:

xml = glade_xml_new (filename, widget_name, NULL);
...
widget = glade_xml_get_widget (xml, widget_name);
g_object_unref (xml);

As mentioned earlier, there is a noteworthy parsing time penalty, if the
XML files grows above certain sizes, no matter whether it's few complex
or many simple dialogs.

I absolutely oppose the idea of keeping unused resources needlessly in
memory, especially if they are to be counted in MBs. I also oppose the
trend that, despite faster CPUs and more RAM all the time, newer
software versions often have to be slower than earlier ones.

> I guess this is a question one has to ask whether you are hardcoding
> it or not.

No it isn't, since if you use hardcode there is absolutely no need to
keep all dialogs prepared but hidden in memory, as there is no noteable
speed penalty if not doing so. Using libglade, however, there is. Not
destroying dialogs but keeping them hidden in memory just because they
contain variable values which aren't stored anywhere else is veeeeery
bad programming style, anyway.

> > - should write extra conviencience funtions to compensate libglade's
> >   deficencies.
>
> Here I really dont follow, libglade hardly needs any adjustments to
> support new features in gtk, whereas when writing code generation
> segments, all that code has to be written by hand.

Well, that point bases on a suggestion by Tim. Actually I've written
such a convenience function, which simulates a Glade-coded
create_my_window () function as create_glade_widget ("my_window"). The
above code lines are a fragment from it. The actual function contains
more workaround, like error checking and signal connecting and stuff. I
don't consider this simplification of (my) code. All that wasn't really
necessary when using Glade-created code.

> Now as for a something like "export plugins" solution, I agree with
> Todd that its probably the way to go, Implementing a smart plugin
> interface for that purpose doesn't scare me; the whole distribution
> process might be a hassle but thats not so bad.

Glade with code generation plugin support would be absolutely okay for
me, especially if a C-code generation plugin would be among the first
available ones.