Re: libglade vs glade for dialog generation
- From: Gus Koppel <gtk spamkiller bytechase cx>
- To: <gtk-app-devel-list gnome org>
- Subject: Re: libglade vs glade for dialog generation
- Date: Wed, 19 Jan 2005 13:37:52 +0100
Tristan Van Berkom wrote:
I have been using Gtk for some months with glade for GUI
development. So far I only use the code generation option of glade
but I saw that some application such as gnumeric only use the xml
file generated by glade(import.glade) and then they load that file
at running time using libglade.
The question is simple, Which way is the best? I will develop and
application which will have more than 20 dialogs therefore i am
interested to know which approach will give the application better
performance-wise you will take a small performance hit at application
initialization time for using libglade (the time it takes to parse the
after that it doesn't make a difference.
Using libglade will:
- Simplify your application code
- Allow you to change your UI without changing your code
Generating code with glade is pretty much depricated by public
Note also that the new generation of glade will not generate code at
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+!
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.
- 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 applicationn with
hardcoded Glade code also is always smaller than an application
without Glade hardcode but an additional libglade XML file.
- Having function calls to build a GUI hardcoded in the program is
faster than parsing XML files at runtime. Speed advantage of
hardcode grows proportionally with the complexity of your GUI.
With a Glade GUI XML file of about 1 MB in size I experienced
a nearly 2 seconds parsing delay everytime(!) before a dialog was
to be opened. There is no delay at all if using Glade code!
- Doing without libglade typically also saves RAM, from some hundreds
KB up to MBs, which may be important for certain target platforms.
- 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 don't see how using libglade instead of Glade code simplifies my
application code? Using Glade code I have a file interface.[ch],
which is not to be touched by the programmer (no need for that
anyway). In my application code I just call Glade-created
create_,my_window () to create my window. Using libglade, a number
of further calls is required to achieve the same, and you have to
add some more care not to create resource leaks.
- As I am not always writing open source software using GTK+ I'd like
the GUI *not* to be easily tamperable with by unauthorized personel,
but rather have the GUI hardcoded into the application itself.
Some points which are not really pro Glade-code but disagree with common
con statements expressed by some people:
- The limit on design complexity doesn't differ between Glade code and
libglade. You can achieve the same complexity with both methods. (But
Glade code will always execute faster, sometimes much faster, than
- Some people complain about differing coding styles between Glade
source and their own source. That's nonsense to me. I don't care
about differing Glade coding style in the same way as I don't
care about differing source code styles between me and other
libraries I use. Both, foreign library sources and Glade code,
should be considered not to be tampered with directly.
- "Experienced GTK+ programmers" who look at you blankly when being
asked about issues or details in Glade-generated code, possibly
unable to help, aren't really experienced, by definition, IMHO.
So my plea, likely on behalf of others as well, is *not* to abandon code
generating facility of Glade! Forcing programmers to use libglade is a
non-trivial compatibility and dependancy breach and bloats applications
in a way, not every programmer who uses GTK+ is willing to accept!
] [Thread Prev