Friday, January 7, 2011

GNOME Outreach Program for Women report - Weeks 2 & 3

I spent most of Week 2 away for the holidays, for christmas we went 350 km (217 miles) south to a beach town, Rafa traveled and saw the ocean for the first time! Nice but exhausting. Here he is, turning into a sand milanesa:

So, on to the report:

I finished the feature to select photo and video sizes independently, This was one of the tickets I started working with when applying for the program. Bug 582268
Back then, the settings were saved using GConf (now being deprecated in GNOME). This is how it looked in gconf editor:

Then Daniel Siegel migrated Cheese to GSettings, which is really great!

To add the new settings I just had to edit org.gnome.Cheese.gschema.xml adding the keys I needed, for example for video x resolution:
    <key name='video-x-resolution' type='i'>
      <summary>Video width resolution</summary>
        The width resolution of the video captured from the camera

make install, and that's it, I could read and save the new values (in vala) using:
private GLib.Settings settings;
int width = 0;

settings.set_int ("video-x-resolution", 480);
width = settings.get_int ("video-x-resolution");

or (in C) using :
int width = 0;
GSettings *settings = g_settings_new ("org.gnome.Cheese");

g_settings_set_int (settings, "video-x-resolution", 480);
g_settings_get (settings, "video-x-resolution", "i", &width);

Really easy and clean. Good to know for any app we want to develop and have save settings capability.

Other issue I found is that in Cheese, the preferences dialog is an "Instant apply" window, as described here:

I quote:

3.3.1. Instant apply windows

For windows that allow the user to change values or settings, such as property and preference windows, update those values or settings immediately to reflect the changes made in the window. This is known as "instant apply". Do not make the user press an OK or Apply button to make the changes happen, unless either:
  • the change will take more than about one second to apply, in which case applying the change immediately could make the system feel slow or unresponsive, or
  • the changes in the window have to be applied simultaneously to prevent the system entering a potentially unstable state. For example, the hostname and proxy fields in a network properties window.
If either these conditions affect only a few of the controls in your window, arrange those controls together into one or more groups, each with its own Apply button. Leave the rest of the controls as instant apply.
  • Do not attempt to validate or apply changes caused by editing a text field control until the user has moved focus to a different control in the window, or the window is closed. Validating after each keypress is usually annoying and unnecessary. Exception: if the field accepts only a fixed number of characters, such as a hexadecimal color code, validate and apply the change as soon as that number of characters have been entered.
  • When the user moves focus to a different control, do not indicate an invalid entry by displaying an alert or undoing the change the user made. Both of these methods are particularly disruptive for focus-follows-mouse users, for whom focus may leave the control more often than it does for a click-to-focus user.

3.3.2. Explicit apply windows

If most of the controls in your window are not suitable for instant apply, consider making the whole window "explicit apply". An explicit apply window has these three buttons in its button box, plus an optional Help button:
  • Apply
    Applies all the settings in the window, but does not close the window in case the user wishes to change their mind.
  • Cancel
    Resets all settings in the window to those that were in force when the window was opened. Note: this must undo the effects of all applications of the Apply since the window was opened, not just the most recent one.
  • OK
    Applies all settings in the window, and closes the window.

Figure 3-5Buttons in an explicit apply window

Also Cheese preferences dialog is not modal, meaning the user can interact with Cheese main window while the preferences dialog is open, and then change settings, and then change something in main window, and change settings again, etc etc. That needed extra steps to ensure the app states remained consistent. (Apply changes to video resolution and photo resolution according to current mode: photo, video or burst mode).

Regarding usability, this kind of dialogs have advantages: no Ok/Apply/Cancel buttons to worry about, the user doesn't have to think, the application is still available instead of blocked. The disadvantage is that once the user changes anything, there is no way back, no cancel button to restore everything to how it was. A "reset to defaults" would be nice to have in some cases.

Other than this, I started to look into Clutter because Daniel had this idea to implement a scrolling effect when changing from one effects page to the next, and it sounds very interesting. I ran the clutter samples found in clutter/tests/interactive, really interesting stuff there. I will be playing around with that next.

Last, I'd like to share a tiny script I use to help me find in files in cheese checkout folder: I search for text in files all the time while developing, but I wanted to exclude some folders (docs, help), and the .c files in src folder (they are generated after .vala files). Everything else I wanted to include in the search. This is very specific to cheese project. So here it is:

grep --color=always -irIn $1 ./src | grep -v "\.c:";
grep --color=always -irIn --exclude-dir=po --exclude-dir=help --exclude-dir=src --exclude-dir=docs $1 .

That's all for now! :)

Ps: use to highlight code or get embedded snippets filtered by ;)

1 comment:

Danni said...

Now that you've ported to GSettings, you should find a Revert to Previous button easy to implement. I think you can track the changes made since the dialog was last opened as a changeset.