Giving the developer a more declarative style of defining the
structure of your GUI

Giving the developer the possibility of definiting the design
of the GUI at a single spot in your program

Being lightweight and easy to learn.

Enough buzzwords

Imagine you want to build a configuration dialog for your
application, which consists of a notebook, to distinguish several
topics, each containing a bunch of simpler widgets (in the
following example a single text entry). Also it should have
the usual Ok and Cancel buttons.

The straight approach often is to code all the stuff by hand
or "draw" all widgets using Glade. At any rate you need to
take care of:

Consistent look and feel, e.g. labels should be bold and
properly aligned to the widgets; the widgets iteslf should
have some space around them, buttons should always be
aligned to the form above etc.

Initializing the widgets with the actual content of your
configuration data

Either connecting a lot of signals to track the changes the user
made. This would apply all changes straight to your internal
data structure, which may make implementing the Cancel button
difficult or impossible

Or grabbing all (changed) data from the widgets, when the
user hit the Ok button resp. simply close the window, when
the user hit the Cancel button

That's a lot of stuff, which needs to be repeated for every
single dialog in your application. No fun anymore.

The Context is a layer which encapsulates the methods of
accessing your object's attributes. Also the Context knows
about relationships between objects and/or their attributes,
so it's able to handle correspondent updates on the GUI side
automatically. We will discuss more details of
Gtk2::Ex::FormFactory::Context later in this document.

Define the structure of your GUI

Create Gtk2::Ex::FormFactory object and define the structure
of your GUI. E.g, you want to have window which contains a
notebook, which consists of a few pages with a bunch of
text entries in them. This will look this way: [ very
compressed and evil nesting for this document - for bigger
dialogs you will break this into several pieces ]

So now you defined that you want to have a text entry,
which contains a valid writable directory name,
which should be inside a form on a notebook page. No details
about the exact layout yet, this is just the strucure
of your dialog

build_TYPE() methods for each FormFactory widget type
(Entry, SelectList, Popup, Foo etc.) you use in your dialog.
These have the Gtk2 code actually necessary to create
the corresponding Gtk2 widgets.

Methods for adding a widget to a container

These are the so called add_WIDGET_to_CONTAINER() methods,
which specify how a
particular widget type is added to a particular container
type. E.g. they're responsible for consistent looking
labels beside widgets etc.

Because the details of adding a widget mainly depend
on the container the widget is added to, there are
generic methods for adding arbitrary widgets to a
container. If there is no specific method for a widget
type this generic method is called instead.

Layout methods for our example

The Layout implementation needs the following methods,
to be able to generate a layout for our FormFactory defined above:

If you regularly code applications with Gtk2 you know, that none
of this tasks is rocket science. But you have a lot of parameters
for each widget in question to take care of (simply think of the
border_width property which may lead to an ugly misaligned mess,
if you don't handle it really consistently)

Because you define this tasks at a single point in your
program, it's really easy to create a consistently looking
application. Or to change the look quickly. E.g. you decide
to put a frame around all your forms? Just change one method -
build_form() - and you're done!

Huh, a lot of new Widget classes to learn!

Not really. The FormFactory Widget classes are very simple and
mainly wrap correspondent Gtk2 widgets, so you don't need to
learn much more.

Using the builtin widgets is really easy. They all ship with
a manual page describing their specific attributes, which usualy
isn't much.

Building your own FormFactory widgets

If you need more widgets: implement them on your own.
Gtk2::Ex::FormFactory widget classes don't have much Gtk2 code
in them, they just define the properties, which represent this
particular form item and implement mainly the following methods:

Define a short name for the type (e.g. "entry" for a Gtk2::Entry -
the Layout->add_X_to_Y() methods are derived from the short name)

Transfer the object's attribute value to the widget

Transfer the widget's value to the object's attribute

Connect the 'changed' signal for a synchronized dialog,
e.g. if you want to react immedately on user input

What the widget and object "value" actually is (a scalar, hash,
array or complex structure) may be arbitrarly defined. How object
attributes are accessed, is defined in the Context module. Our
example uses the default set_foo(), get_foo() style accessors, but
there are more methods up to defining callbacks, which can do very
complex lookups.

Data consistency

Now we know that the FormFactory suite solve layout issues very
well. Another important feature is automatic data consistency
resp. keeping the GUI and your application data in sync.

Change an object attribute: the correspondent GUI widgets will
update automatically. The user entered data to a text entry:
the object attribute associated with this entry will automatically
get the new text.

Abstraction from your application's objects

All your application objects are registered with a unique name
to the Context module. Each FormFactory has a reference to
this Context, so it know the objects which are registered.

When you register your object to the Context, you may specify
how attributes are accessed by setting prefixes for read/write
accessors.

You may even override methods inside the Context by specifying
correspondent closures, which are called instead of the original
method.

Also objects in terms of the Context module may be abstract things like
"The currently selected disc from the currently selected artist",
not only a simply hardwired object reference. This is done by
calling a closure returning the actual object instead of using
a hardwired object.

This way dependend widgets update automaticly, as soon as the
correspondent selection changes, e.g. updating a list of CD titles
when switching to another disc in an imaginary CD database program.

Widget consistency

Another challenge in a good GUI program is to make your widgets
consistent in terms of graying out widgets, which are not useful
in a particular state of your program.

Gtk2::Ex::FormFactory manages visibility and sensivity of your
widgets automatically for you once you registered the correspondent
dependencies at the Context. E.g. if there currently is no CD
album selected, the corresponding fields are greyed out automatically,
including the field labels.

Data validity

Gtk2::Ex::FormFactory specifies Gtk2::Ex::FormFactory::Rules,
which are checked against the values the user entered. These
conditions must apply, otherwise the old values are restored
automatically. A bunch of rules are shipped, but you can define
your own set by specifying a correspondent rule object or closures.

Define your own FormFactory Layout module, by deriving from the
default Layout implementation and passing a correspondent object
to the FormFactory constructor.

All items in your FormFactory have a name, which will be set by
default or to a value, you pass to the item's constructor.
This way your Layout implementation can even do very special
things for very special widgets, without the need of creating
an extra Widget module for this.

You can request any Gtk widget from a FormFactory widget by name
to do further manipulation, although you should consider doing
this inside your Layout implementation, to keep the "single point
of layout" rule.

This library is free software; you can redistribute it and/or modify
it under the terms of the GNU Library General Public License as
published by the Free Software Foundation; either version 2.1 of the
License, or (at your option) any later version.

This library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Library General Public License for more details.

You should have received a copy of the GNU Library General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307
USA.