RE: Modularization

["Freddie Unpenstein" <fredderic excite com>]

> I'm beginning to learn and use GTK+. Here is the steps that I
> believe are needed to build an GTK+ application:

> 1. Initialize the library.

Generally happens in main...

> 2. Create widgets and set attributes.
> 3. Register callback routines.

Those two go together...  Either load a glade UI and auto-connect the callbacks, or construct your UI 
manually and attach the callbacks as you go along.  Either way, I like to have a module (pair of .c and .h 
files) that handles the creation and interraction with the UI.

> 5. Show widgets.

Quite often in main, I'll call a function like create_main_win(), which does everything but actually show the 
window.  Then I'll pass that to gtk_widget_show_all() to actually display it.

> 4. Define widget hierarchy.

In one case I built an entire main window, then there's one particular central widget that needed extra 
handling, so I put it into its own "module" in a similar manner.

In the end, it all comes back to the same old program design principles as everything else.  You see a large 
component that can exist as a discrete unit, so you put it in its own file, even if it's only used in one 
place.  You regulate access to the component through an API (the .h file), and if appropriate, you take the 
extra step of wrapping it up in a GObject or GtkWidget derivative.

A little fore-thought and you can easily present a very GObject-ish API right from the beginning.  Then when 
you want to turn it into a full GObject, it's already most of the way there.

I did that wish an image library viewer I wrote for a very specific purpose.  The part that actually displays 
the image turned out quite neat, and happened to be based on GtkDrawingArea.  So I rolled it up into a new 
widget decended from GtkDrawingArea, and wrote a one-file-wonder that puts that component into a window with 
an xmessage-style option to present some "caption text" and buttons across the bottom.  I use it as a quick 
image viewer (similar to xli, but with one or two features I felt was missing), and a xmessage replacement 
that can display a picture over the text and buttons.

If I ever find another use for that image viewer "module", I'll move it into my little home-grown library 
collection as a full-fledged distinct widget.  There's already a bunch of wrapper functions for times when I 
don't want to include the entire stdio.h or string.h for just one function, another that contains little 
routines which I personally think seem to be "missing" from the GTK API, and a tooltip derivative that allows 
marked up tooltips if they begin with the <markup> tag.  The three personal libraries all started off the 
same way, as components of another program which I had collected together and distinct because I figured they 
might be handy somewhere else.

> 6. Process signals and events.

Some signals are purely internal to a given component, and should reside in the same module.  Other signals 
involve the encompasing UI or process, for which you start by simply linking to functions outside of the 
module, but with that little bit of fore-thought, can easily replace with a signal later on.

> 7. Quitting

In most cases this is as simple as setting gtk_main_quit() as the signal handler for destroy on the main 
window.


Fredderic

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!