Re: libglade vs glade for dialog generation
- From: Tim Müller <zen18864 zen co uk>
- To: gtk-app-devel-list gnome org
- Subject: Re: libglade vs glade for dialog generation
- Date: Wed, 19 Jan 2005 17:25:59 +0000
On Wednesday 19 January 2005 12:37, Gus Koppel wrote:
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
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
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.
] [Thread Prev