GTK+ 3.0 introduced gtk_tree_model_iter_previous() so we no longer need to
keep this helper function.
Also, simplify the use of GtkTreeIters by allocating them on the stack.
https://bugzilla.gnome.org/show_bug.cgi?id=652374
Setting updating_settings in update_layouts_list() and checking for it in the
gsettings 'changed' signal handler doesn't prevent a loop because the signal
handler is only called after update_layouts_list() returns and thus
updating_settings is already FALSE at that point.
By using the 'drag-end' signal instead of 'row-inserted', etc. we continue to
support DnD re-ordering of layouts while avoiding the loop from
xkb_layouts_fill_selected_tree() deleting and inserting rows into the model.
https://bugzilla.gnome.org/show_bug.cgi?id=652361
Currently the lock button's visibility is updated on permission
changes - if the active panel does provide a permission object,
the button is shown, otherwise hidden.
As GtkLockButton itself does manage its visibility, it is not
necessary to handle it in g-c-c. In fact it is harmful, as the
more sophisticated handling in GtkLockButton is overwritten: for
instances, GtkLockButton hides itself if an action is allowed and
the permission can not be released. By overwriting the behavior,
gnome-control-center ends up showing a non-functional button.
https://bugzilla.gnome.org/show_bug.cgi?id=652299
Setting the date manually should be disabled when using NTP, but
the "Network Time" setting is not taken into account when updating
sensitivities after permission changes. As a result, the date is
always editable after unlocking the panel - to fix, take the NTP
setting into account on permission changes.
https://bugzilla.gnome.org/show_bug.cgi?id=652240
The libcolord async API used to use a thread to get the properties for the
device and profiles in the background.
This was racy as hell, and was not good API design. Connect to each device and
profiles explicitly before we access the properties.
