Re: libglade vs glade for dialog generation

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 

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]