If no items are added to the GVariantBuilder, g_variant_builder_close()
would throw a critical, g_variant_builder_end() would throw a
segmentation fault.
As this can only happen when there are no items added to the output_ids
hashtable, this should only happen if there are no displays known to
libgnome-desktop (and therefore mutter).
See https://bugzilla.redhat.com/show_bug.cgi?id=1280075https://bugzilla.gnome.org/show_bug.cgi?id=771875
This patch introduces a change to the Lock/Unlock logic. From now
on, unlocking the panel causes the "Lock" button to turn into the
"Add Printer" button.
https://bugzilla.gnome.org/show_bug.cgi?id=767600
This toggle is always set to off when the panel is opened. We should
check whether it's on or not when opening the panel. Currently we are
only subscribed to changes, so we don't check the wifi state until it's
toggled on or off after the panel has been opened the first time.
https://bugzilla.gnome.org/show_bug.cgi?id=771564
They should probably have been unsigned integers, but they're not, so
warn if they are. The rest of the code handles negative values as if
they were 0.
https://bugzilla.gnome.org/show_bug.cgi?id=771542
From https://bugzilla.gnome.org/show_bug.cgi?id=765969 as explained by
Dan Winship:
"
libnm-util/libnm-glib had a buggy data model, which nm-connection-editor
(and then gnome-control-center) copied, in which each manually-configured
IP address has an associated gateway address. In reality, NM always just
took the first non-empty gateway value from the address array, and
completely ignored any other gateway values.
libnm represents this more accurately, by having a single gateway
value which is separate from the address array. Ideally, the editors should
show it this way as well (eg, like nmtui does). Failing that, it would
be nice to at least make it so that only the first row in the address
table can have a non-empty gateway value.
"
We went for the second option, only showing a gateway entry for the
first address in the list.
This isn't related to route-specific gateway addresses.
https://bugzilla.gnome.org/show_bug.cgi?id=765969
The mask returned by gtk_accelerator_get_default_mod_mask() should
work without additional filtering, in particular when it is overly
restrictive - a lot of shortcuts use the Super modifier nowadays,
so stop filtering it out.
https://bugzilla.gnome.org/show_bug.cgi?id=771058
gtk_accelerator_valid() doesn't accept Tab as keyval, so using it to
check whether a shortcut is valid breaks commonly used shortcuts like
Alt+Tab. Unbreak those by adding a small wrapper that special-cases
Tab-with-modifiers.
https://bugzilla.gnome.org/show_bug.cgi?id=771058
Before, when pressing "Backspace" in the editing dialogue, the
keybinding would be changed straight away, *behind* the dialogue, and
the dialogue would still be expecting a new shortcut.
Instead, we should make it behave like other shortcuts, which means
special handling empty shortcuts as valid ones.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
We couldn't override gnome-shell's keybindings without having a working
grab, but the grab was only started when clicking the "edit" button when
editing a custom shortcut, or *after* receiving the first key press event.
To fix that problem, we need to grab the keyboard once we've shown the
dialog itself, but not in the ->map vfunc, otherwise it will block the
dialog from showing up. We set up a short timeout instead. Hopefully
this isn't too fragile.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
In a0a15588, we starting using a separate shortcut editor window, which
was doing its own capture instead of using the GtkCellRendererAccel. But
this started grabbing both keyboard and pointer, making it impossible to
cancel captures using the pointer.
We now only grab keyboard keys, making the pointer usable again.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
While waiting for keyboard input, as per the new proposed mockup,
the shortcut editor dialog should show a custom page with an icon
that indicates the required action. The current code, however, does
not expose this new customized page.
Fix that by adding this new page and controlling the time when it
shows and hides.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
The Reset button, according to the mockups, should be placed
at the right side (left on rtl) of the shortcut label. Also,
rather than a plain string, the button should use a symbolic
icon for 'edit-clear' action.
This patch moves and updates the Reset button to match the
mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
When adding a new keyboard shortcut, in accordance to the mockups,
the dialog should present a new page calling for an action from the
user.
This patch adds this page, and adapts the code to show it whenever
the user wants to change the shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
When editing a standard shortcut, the current code only
cancels the editing on Escape, but doesn't hide the
dialog.
Fix that by properly handling the canceling of shortcut
editing and making sure we always hide the dialog on
cancel.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
Instead of manually handling every button in the headerbar
individually, using states to switch between modes. It's clearer
and easier to maintain.
This patch adds the headerbar mode handling code, and updates
the current code to use it rather than by updating each individual
button manually.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
Instead of showing the shortcut description, show an
action-oriented title, according to the mockups. Precisely,
"Set Shortcut" for standard shortcuts and "Set Custom
Shortcut" for custom shortcuts.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
The current button to reset shortcuts is represented by the
'x' icon, which induces the user to think this is a remove
button rather then a reset button.
Fix that by using edit-clear-symbolic icon to represent the
reset action.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
When creating a new keyboard shortcut, the Add button gets
sensitive when all the fields are valid. If the user tries
to create a new shortcut right after closing the shortcut
editor dialog, the Add button is still sensitive even with
invalid custom fields.
Fix that by making the Add button sensitive whenever we
finish editing the new custom shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
Gtk+ changed again the behavior of the scrolled window,
fixing the weird height issue but introducing a new issue
where the keyboard shortcut list doesn't expand horizontally
nor allocates the correct size vertically.
Fortunately, this is easily solvable with the newly introduced
GtkScrolledWindow:propagate-natural-width and -height
properties.
Fix the misbehavior by setting the new properties to sane
values.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
