Re: libglade vs glade for dialog generation

[Gus Koppel <gtk spamkiller bytechase cx>]

Tim Müller 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.

Marvelous. If code generation is such a trivial process, then why not
just leave it inside Glade? Why bother users of that feature with
external scripts or programs they would possibly have to write first? A
small plugin system in Glade for code generation for different
programming languages would probably be even more trivial, wouldn't it?

I mean, you wouldn't completely seperate the code to draw or select
circles from The Gimp, just because it's little effort to write an
external program to achieve the same, would you? Even if such an
external program could support non-standard extensions like rotated or
deformed ellipses, it would be much easier (esp. for the user) to keep
that functionality within The Gimp, maybe accessable as a plugin.

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

On my Linux system the dependancy difference between compiling + linking
with or without libglade support is: libglade, libxml2, libz and
libpthread. Originally I believed libexpat belongs to it too, but here I
was mistaken. libexpat belongs to the libxft periphery, rather.

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

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

It's not only the XML file but also all the additional libraries which
need to be loaded and require their own data objects in RAM. Besides, I
have a Glade XML file that's more than 1 MB in size. All together adds
more than 2 MB of RAM consumption as a minimum, compared to hardcode.

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

You suggest writing a number of extensions, i.e. Perl scripts to
generate code, or own convenience functions to better deal with
libglade. None of it is required when just using the Glade generated
code. To me, this sounds like asking many programmers to reinvent the
wheel on their own, just because the original wheel has become
deprecated by its inventor. Someone else recently mentioned, using
libglade would be easier, i.e. simplifying the code. I contradicted
prior to your suggestions, but they make it even more obvious that using
libglade isn't a simplification for writers, compared to Glade code.

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

Understanding or examining the way and order in which containers and
contents are placed and attributes are set by using GTK+ API isn't a
question of aesthetics to me, but rather a question of fundamental
understanding of how to program a GUI using the GTK+ API.

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

Other ways, yes, but not necessarily better ones. For beginners,
tutorials are certainly a preferred way to gather basic understanding.
However, if you already have a complex layout and make use of many of
the widget's attributes that are supported by Glade, it's certainly more
helpful to examine how Glade managed to translate your custom design
into ordered GTK+ API calls. Especially if yoy want to learn how to
apply custom runtime modifications from other parts of the program.

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

So the idea is to remove an existing, comfortable, helpful and
apparently fairly popular Glade feature, just to let it be reinvented by
others in form of additional tools, which would certainly make software
creation process yet more complex (without need, AFAICS)?

Let me briefly sum up, again. Using libglade + XML file instead of Glade
generated code means, you
- have more external library dependancies, therefore
- have higher disk space consumption
- have greater installation package if it's to be self-contained
- have higher RAM conumption at application execution time
- have lower application execution speed (dialog open delays)
- should write extra conviencience funtions to compensate libglade's
  deficencies.

Relevance of i.e. some hundred KBs extra harddisk space allocated, is
matter of taste, of course, but the general direction or trend is fact.

I'm personally very glad that I still have the choice not to do it that
way and will certainly become fairly unhappy with GTK+ application
development if I HAVE TO do. And I don't think I would be the only one.

P.S.: sorry, if you believe this posting better belongs into Glade's own
list. I basically agree.