Re: libglade vs glade for dialog generation

[Roger Leigh <rleigh whinlatter ukfsn org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gus Koppel <gtk spamkiller bytechase cx> writes:

> Roger Leigh wrote:
>
> > > > > - 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 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.
> >
> > I don't agree with these assertions.  While Glade-generated code is
> > certainly convenient, I don't believe that it is better (I don't
> > personally like the generated code).
>
> Well, regarding resource requirements and execution speed of a given
> application, Glade-code *is* better than Glade-XML. That's no question
> of belief.

My issue isn't with the speed--it's the quality of the code.  It
works, but it's not as good as hand-crafted code (see below).

> As I mentioned earlier, you don't need to look at the Glade-created code
> ever, except if you want to learn from it. You must not modify
> interface.c on your own, anyway. Just treat interface.c the same way as
> likely any source file from any other library you use: don't care about
> its contents, just utilize its results.

Sure, but if you work this way, you end up with a big homogenous blob
of code plus a stack of callback functions.  My biggest problem with
this is that there's very little structure to the code (you snipped
this in your reply).  You get no code reuse and you can usually only
instantiate one copy of the interface due to having to keep a lot of
state in global variables.

libglade does not in itself solve any of these problems, but it does,
if you permit it, allow one to root the widget tree in a
GtkWidget-derived object, and then use that as you would any "native"
GtkWidget.  You now have a native object which you can instantiate
multiple instances of, derive from, emit signals from etc..  You now
have decent object-oriented code instead of a big list of callbacks.

> Just think about a number of forms with combinations of i.e. 200 text
> entries, comboboxes, radiobuttons and checkmarks in them. Several
> variations of those forms with totally individual widget layout variants
> exist. This sounds worse than it looks, if properly designed, but can
> quickly grow a Glade XML file beyond the 1 MB border.

At that point, I'd personally start generating them in code, since
both the Glade interface and the Glade-generated code will be bigger
and slower at this point.


Regards,
Roger

- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFB8oJUVcFcaSW/uEgRAmMzAJ90+KWo9AzPkiz6/bvkqZiesUfQIgCfUKIY
AQh9C5K496PUl68WDS60Kf8=
=Zmdb
-----END PGP SIGNATURE-----