RFC: Ideas for preferences dialog

[James Liggett <jrliggett cox net>]

Hi,
For a couple of weeks now I've been formulating some ideas as to how we
could implement our prefs dialog so that my resolution changing patch
can finally get into trunk. :-)

First, I think we should reimplement CheeseGConf to make it easier to
add new keys to the system. Currently, we're using GObject's property
system, which makes it easy to set and get many keys at once in a
type-safe manner. But, there's a lot of extra work to be done to do
this. To add new keys, you have to register the key as a property of
CheeseGConf, and then you have to add the set/get stuff in the
appropriate functions. However, GConf provides its own type-safe
mechanism for setting and getting option contents. So, what I propose is
to eliminate the use of GObject properties, and replace them with our
own methods that act the same way as g_object_set/get. We can accomplish
this easily with the GConfValue API and gconf_value_set/get. If we do
this, new keys can be set up only by adding to the schema file--the rest
is handled internally.

And then there's the issue of actually setting up the widgets in the
dialog to reflect the contents of the keys and then setting keys in
response to user actions on the widget. For this I think we should have
a set of polymorphic GObject classes that handle this stuff for us, and
another object to contain these. For the sake of argument, I'll call
this container class CheesePrefsDialogWidgets (I'm open to suggestions
on naming ;) . 

As an example, let's say I'm building a dialog for resolution changing,
and in this dialog I have a GtkComboBox where I have the user select
resolutions. To start, I create the base class, which I'll just call
CheesePrefsWidget . This class will contain a public property to hold
the GtkWidget (obtained from GtkBuilder) that this particular key (or
keys) is to be synchronized to, as well as another public pointer to
CheeseGConf so that children can get the GConf data they need. The class
will also have a pure virtual method ::synchronize, where the widget
would actually be directed to reflect what's actually in the given keys.
This method would be called by the container described above so we don't
have to do it ourselves for each key/widget. It would also build and
populate any data models or structures if needed.

Next, I actually create the CheesePrefsWidget derivative that actually
does the dirty work of grabbing resolutions from CheeseWebcam, and
populating a GtkComboBox with them. I'll just call this
CheesePrefsResolutionCombo. This class will contain the GtkTreeModel
that contains the resolution information. It will be populated and set
to the proper resolution by its implementation of ::synchronize. It will
also have two properties, max_x_resolution, and max_y_resolution, for
controlling the maximum resolution that can be shown/selected in the
combo box, as well as other properties telling the object which GConf
keys to look at. The object will also listen for any kind of selection
change signal, and update GConf as needed. 

Other types of widgets/keys would be handled in a similar fashion. This
method is especially useful if we have two or more similar types of
keys, like different resolution settings for pictures and video, as was
proposed earlier. We can encapsulate all the messy work of handling all
of this and automate as much of it as possible, keeping the GUI code of
the dialog itself relatively clean. 

Hope this isn't too confusing ;) Suggestions welcome...

Thanks,
James