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? daniel > > Thanks, > James > > _______________________________________________ > Cheese-list mailing list > Cheese-list gnome org > http://mail.gnome.org/mailman/listinfo/cheese-list -- this mail was sent using 100% recycled electrons ================================================ daniel g. siegel <dgsiegel gmail com> http://home.cs.tum.edu/~siegel 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