default_app_changed() contains a typo: we need to set the https
handler app when the user changes the http app chooser, not the
(non-existent) https app chooser.
Install stuff in /usr/local, desktop icon shows up, and it doesn't
work. That's because it can't load the GIO extension. Yell like a madman
about it.
https://bugzilla.gnome.org/show_bug.cgi?id=652583
A menu popup was the best thing we could find after discussing it on
If anybody has any better ideas then please shout / send patches.
To show the menu, press the context menu key on the keyboard.
Don't use pango_cairo_layout_path(), which doesn't do any
hinting whatsoever, use gtk_render_layout() from GTK+ instead,
as the text cell renderer already does.
With help from Matthias Clasen <mclasen@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=652709
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
