Re: GUI programming vs encapsulation

[Roger Leigh <rleigh whinlatter ukfsn org>]

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

Daniel Haude <dunno stoptrick com> writes:

[Code organisation]
> 1. Separate source files for each dialog.
>     -> unpractical because this is a single Glade project, and Glade
> only writes single source files.

That's true.  You could have a separate Glade file for each widget,
however.

> 2. Storing information about widgets (i.e., pointers to widgets)
> inside the parent top-level widget using the G_OBJECT methods
> (g_object_set_data() and friends), and finding the widget with the
> lookup_widget() funcion supplied with Glade
>     -> I somehow don't like it. I like mean, lean, and fast programs,
> and the mere thought that each push of a button or movement of a
> slider generates an avalanche of hash lookups gives me ulcers, and it
> litters the code with "magic" lookup key strings.

You could store the widgets you need in a pointer to a dedicated
structure, saving the expense of all the lookups (do the lookups once,
at creation time, and store the results here).

> 3. For each widget, declare a global pointer variable, a "create"
> and a "delete" callback.

That sounds messy.

> Currently I'm using a mixture of 2. and 3. (depending on how I feel
> that day), but leaning towards 3. without much passion.
>
> So how do you guys deal with this problem? I guess there is no real
> way out of having all the callbacks spread out in this "flat" fashion
> because from the C program's point of view there's no telling in what
> order they might be called. Is writing unwieldy spaghetti code a
> necessary part of GUI programming, or have I missed some important
> point?

A while ago, I ran into the same problem, though I wasn't using Glade
code generation.  Looking through the Gnumeric source code helped me
immensely, seeing how a large GTK+ application was structured.  My
project is here:

http://www.whinlatter.ukfsn.org/gtk/uterm-0.1.0.tar.bz2

You might find cse/cse-mainwindow.[ch] and cse/cse-char-edit.[ch] of
interest.  These are both objects making use of Glade/libglade.
cse/cse-selection.[ch] might also be of interest; it's a object
derived from GObject with its own properties and signals which is made
use of by other objects to connect changes in the selection to update
handlers in disparate objects.  The other objects in cse/cse-*.[ch]
and uterm/uterm-*.[ch] are other objects (including widgets) derived
from other GObjects.  There's some documentation in doc/api/.

I don't claim to be an expert though!--this is the first project I've
structured in this way.


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.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCBRiXVcFcaSW/uEgRAgBkAJ0XOd+oreRO//xyTiy6PCrnaQcOTACaA7fA
S8c1U5L6qsJPPkXP3duUQPE=
=LzYL
-----END PGP SIGNATURE-----