Re: libglade vs glade for dialog generation

[Gus Koppel <gtk spamkiller bytechase cx>]

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.
>
> performance-wise you will take a small performance hit at application 
> initialization time for using libglade (the time it takes to parse the
> XML file),
> 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
> opinion.
>
> 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+!

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
  libglade)

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

<offtopic_request>
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!
</offtopic_request>