Re: RFC: Ideas for preferences dialog

awesome.. just awesome ;) 

On Mo, 2008-03-31 at 17:00 -0700, James Liggett wrote:
> 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.

i used the gobject set/get as i didnt find any other way to do simple
type-safe setting/getting of properties. i even dont know the gconf
mechanism, at least i didnt find it ;)
but if you are telling me, that this is much easier, it is no problem to
add that feature

> 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.

this is very complex.. did you plan to add the widgets in the code? i
would prefer glade/gtkbuilder for the preference window. the synchronize
option is very nice though, to easy update the gconf settings.

> 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. 

hmm.. i think handling resolutions is just too complex for the average
user... what about having 3 entries, like "small", "medium", "large"? we
could extend that even to 5 or so

> 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...

youre awesome ;) need help implementing this?


> Thanks,
> James 
> _______________________________________________
> Cheese-list mailing list
> Cheese-list gnome org
this mail was sent using 100% recycled electrons
daniel g. siegel <dgsiegel gmail com>
gnupg key id: 0x6EEC9E62
fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62
encrypted email preferred

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]