Re: libglade vs glade for dialog generation

[Gus Koppel <gtk spamkiller bytechase cx>]

Roger Leigh wrote:

> > > > - Doing without libglade typically also saves RAM, from some
> > > > hundreds  KB up to MBs, which may be important for certain target
> > > > platforms.
> > >
> > > If that is a concern, mmap() your .glade file into memory, and use 
> > > glade_xml_new_from_buffer().
> >
> > It's not only the XML file but also all the additional libraries
> > which need to be loaded and require their own data objects in RAM.
> > Besides, I have a Glade XML file that's more than 1 MB in size. All
> > together adds more than 2 MB of RAM consumption as a minimum,
> > compared to hardcode.[...]
> > You suggest writing a number of extensions, i.e. Perl scripts to
> > generate code, or own convenience functions to better deal with
> > libglade. None of it is required when just using the Glade generated
> > code. To me, this sounds like asking many programmers to reinvent
> > the wheel on their own, just because the original wheel has become
> > deprecated by its inventor. Someone else recently mentioned, using
> > libglade would be easier, i.e. simplifying the code. I contradicted
> > prior to your suggestions, but they make it even more obvious that
> > using libglade isn't a simplification for writers, compared to Glade
> > code.
>
> I don't agree with these assertions.  While Glade-generated code is
> certainly convenient, I don't believe that it is better (I don't
> personally like the generated code).

Well, regarding resource requirements and execution speed of a given
application, Glade-code *is* better than Glade-XML. That's no question
of belief. And those should be the two primary interests of users. Users
will hardly be interested in whether the programmer likes code parts
which were added by "someone" else or not.

As I mentioned earlier, you don't need to look at the Glade-created code
ever, except if you want to learn from it. You must not modify
interface.c on your own, anyway. Just treat interface.c the same way as
likely any source file from any other library you use: don't care about
its contents, just utilize its results.

> I imagine that the 1 MiB Glade file describes quite a complex
> interface, but when I'm writing a program, I generally find that a
> single "monolithic" interface is not sufficiently structured to
> allow for a good overall design. I can usually soon spot particular
> widgets, or sets of widgets that have particular responsibilities,
> which are really objects in their own right. For these cases, it
> makes sense to derive new first-class widgets to really take
> advantage of the framework GTK/GLib offers.

Just think about a number of forms with combinations of i.e. 200 text
entries, comboboxes, radiobuttons and checkmarks in them. Several
variations of those forms with totally individual widget layout variants
exist. This sounds worse than it looks, if properly designed, but can
quickly grow a Glade XML file beyond the 1 MB border.

> > Let me briefly sum up, again. Using libglade + XML file instead of
> > Glade generated code means, you
> > - have more external library dependancies, therefore
> > - have higher disk space consumption
 
> Agreed, but it's only two libraries, which are standard on all Linux
> distributions, and on a typical desktop are probably already in use.

I counted 4 extra libraries. And please don't think in Linux only if you
consider GTK+ software.

> > - have higher RAM conumption at application execution time
> > - have lower application execution speed (dialog open delays)
>
> This is very true, but I guess this is one of the places where you
> trade speed for convenience, and you can always unref the GladeXML
> object once the UI has been constructed.

No, it's trading speed for inconvenience. Above you agreed that Glade
code is certainly convenient. And it's the fast way. libglade is the
slower and more resource-hungry way. And to me it's also (a bit) more
inconvenient. I had to write my own convenience function to emulate a
Glade's create_my_window () call as libglade-conforming
create_glade_widget ("my_window"); Having to write that, along with
worse performance, isn't convenient to me at all.