Re: libglade vs glade for dialog generation

[Tim Müller <zen18864 zen co uk>]

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+!

Just because Glade itself doesn't generate code any longer doesn't mean that 
you won't be able to generate code from Glade output any longer, it just 
means it won't be Glade itself doing it. It shouldn't be much effort to write 
a perl script (or whatever) that generates code from .glade and .gladep 
files. In fact, separating code generation from Glade opens up a whole lot of 
new possibilities, e.g. code generation for languages other than C and the 
like, integration with automake, maybe even better IDE integration. 


> I've been working with libglade for a while but returned to Glade
> generated code. There is a handfull of reasons for that, which may or
> may not apply to others as well:
>
> - Using libglade adds a number of annoying dependencies of external
>   packages to your program. Without libglade only core GTK+ libs are
>   required. Especially on non-Linux-plattforms you would hardly be
>   able to distribute your application without a fairly large bunch
>   of required extra software to be installed. Most average Windows
>   users for instance would neither understand why this is necessary
>   nor be willing to do so.

Which 'handful' of dependencies is that? libglade requires nothing but Gtk+ 
and dependencies and libxml2. So that is one single additional dependency, 
and even that you can get rid of with a small patch I posted to the glade 
devel list a while ago which makes libglade use GLib's GMarkupParser instead 
of libxml2. So if the libglade dependency really annoys you, and/or you want 
to make life easier for win32 folks, don't link against libglade, but instead 
just drop the libglade code into your program and apply that patch (might 
lead to problems with the license of course).

Also, I seem to remember that there are (were?) plans to integrate 'something 
like libglade' (whatever that means) into Gtk+ at some point. It used to be 
on the 2.6 plan IIRC, not sure what happened to it.


> - If you plan to distribute a self-contained package, i.e. include
>   everything that's needed (especially GTK+ Runtime Environment) into
>   your package, you can save quite some size (download time) without
>   the extra stuff being required by libglade. An application with
>   hardcoded Glade code also is always smaller than an application
>   without Glade hardcode but an additional libglade XML file.

See above for 'the extra stuff being required by libglade'. I am not sure 
whether saving a couple of kilobytes in download size is really a good 
argument for or against Glade code generation. Even huge glade XML files 
should compress really well, and, to me at least, my time is more important 
than adding 50kB to a package download (unlike me, you might find code 
generation to be a time-saver, of course)


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

You don't really need to keep around the GladeXML data either - just extract 
all the widgets you need and put them in a struct and then get rid of the 
GladeXML structure (admittedly libglade is lacking convenience functions for 
this, but those shouldn't take more than 30 lines to implement anyway).


> - Glade code can serve as a good tutorial on how to program GTK+
>   directly. You may appreciate this knowledge when it comes to
>   runtime modifications of already created windows, i.e. modifying
>   sensivity, visibility or even layout of widgets.

I beg to differ, but I suppose in the end this is more a question of 
aesthetics anyway. 

Also, this point only really applies to people unfamiliar with the Gtk+ API. 
For those people there must surely be better ways to get familiar with the 
those functions than looking at Glade generated code, no? Even if not, those 
people will still be able to look at the code generated by one of the many 
code generation scripts that will surely come into existence once the 
generation feature is removed from the core Glade codebase.

Cheers
 -Tim