This fixes:
==5944== 2,304 bytes in 5 blocks are definitely lost in loss record 15,724 of 16,045
==5944== at 0x4C2AB9D: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5944== by 0x1445F0B8: g_realloc (gmem.c:159)
==5944== by 0x144217CF: g_array_maybe_expand (garray.c:779)
==5944== by 0x14420C9F: g_array_append_vals (garray.c:418)
==5944== by 0x48ACFA: append_sections_from_file (keyboard-shortcuts.c:558)
==5944== by 0x48B4EE: reload_sections (keyboard-shortcuts.c:737)
==5944== by 0x48EA22: keyboard_shortcuts_init (keyboard-shortcuts.c:2109)
==5944== by 0x489236: cc_keyboard_panel_constructor (cc-keyboard-panel.c:133)
==5944== by 0x141C7C3F: g_object_new_with_custom_constructor (gobject.c:1697)
==5944== by 0x141C7E71: g_object_new_internal (gobject.c:1777)
==5944== by 0x141C8ADA: g_object_new_valist (gobject.c:2038)
==5944== by 0x141C7A85: g_object_new (gobject.c:1622)
==5944== by 0x4547DF: cc_panel_loader_load_by_name (cc-panel-loader.c:213)
==5944== by 0x44DFCB: activate_panel (cc-window.c:157)
==5944== by 0x4504D6: cc_window_set_active_panel_from_id (cc-window.c:1036)
==5944== by 0x44E6A6: item_activated_cb (cc-window.c:280)
https://bugzilla.gnome.org/show_bug.cgi?id=756762
==5944== 90 (16 direct, 74 indirect) bytes in 1 blocks are definitely lost in loss record 11,855 of 16,045
==5944== at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5944== by 0x1445EFCC: g_malloc (gmem.c:94)
==5944== by 0x1445F2AE: g_malloc_n (gmem.c:330)
==5944== by 0x144982EC: g_variant_dup_strv (gvariant.c:1621)
==5944== by 0x13EDF251: g_settings_get_strv (gsettings.c:2070)
==5944== by 0x48D56E: find_free_settings_path (keyboard-shortcuts.c:1651)
==5944== by 0x48D663: add_custom_shortcut (keyboard-shortcuts.c:1682)
==5944== by 0x48DB04: add_button_clicked (keyboard-shortcuts.c:1788)
https://bugzilla.gnome.org/show_bug.cgi?id=756762
If the gsettings key for the command or name of a custom shortcut is not
writable, the keyboard panel still lets you edit them. This commits
makes the corresponding widgets unsensitive when the gsettings key is
not writable.
https://bugzilla.gnome.org/show_bug.cgi?id=749381
It's part of CcKeyboardItem but nothing uses it. It's also parsed
when loading KeyListEntry XML, but never used. The key description is
translated using Keylist::package before gettext_package is assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=749381
It is possible to press the Add button in the custom shortcut dialog
when the name and command fields are empty. Disable the button by
default, and only enable it when the name and command is non-empty.
https://bugzilla.gnome.org/show_bug.cgi?id=739647
By stopping watching for WM changes when leaving the shortcuts panel.
#0 reload_sections
#1 wm_window_event_filter
#2 gdk_event_apply_filters at gdkeventsource.c:81
#3 gdk_event_source_translate_event at gdkeventsource.c:195
#4 _gdk_x11_display_queue_events at gdkeventsource.c:338
#5 gdk_display_get_event at gdkdisplay.c:313
#10 g_main_context_iteration at gmain.c:3766
#11 g_application_run at gapplication.c:1623
See https://bugzilla.redhat.com/show_bug.cgi?id=1094480https://bugzilla.gnome.org/show_bug.cgi?id=736117
When disabling a keybinding, we set its value to { "", NULL } in gsettings
(bindings are stored as arrays of strings).
However, when a binding is disabled by default, its value is set to {
NULL }, not to the empty string.
The use of "" dates back to gconf where I think NULL was not a valid
value. Now that we have switched to gsettings, we can use NULL rather
than an artificial "".
https://bugzilla.gnome.org/show_bug.cgi?id=732383
If a KeyListEntry has a hidden="true" attribute, then the corresponding
binding information will be loaded as usual, but the binding won't be
displayed in the user interface.
This is useful as the keyboard panel will take into account hidden
keybindings when detecting conflicting shortcuts, or to suggest to set a
reverse shortcut.
For now, this will be used for the various reverse mutter keybindings
({switch,cycle}.*-backward) as they should not be shown in the UI, but
we still want the keyboard panel to know about them.
https://bugzilla.gnome.org/show_bug.cgi?id=731618
Since we now know when a binding has a 'reverse' binding, we can now
suggest to update the 'reverse' shortcut when the user set a shortcut
for one of them.
https://bugzilla.gnome.org/show_bug.cgi?id=731618
The code to listen for window manager changes only makes sense under
X, so don't use it under Wayland. In that case, we can just assume
that we are under GNOME shell when we find a wayland display.
https://bugzilla.gnome.org/show_bug.cgi?id=728679
These keyboard switching key combinations had been rejected because
using them as shortcuts might prevent users from inputting text. But
now the input source switching keys are configured and processed in
GNOME. So the shortcut settings should allow these key combinations.
https://bugzilla.gnome.org/show_bug.cgi?id=693395
The default focus traversal order inside the shortcuts tab was: the
shortcuts treeview, the section treeview and the shortcuts toolbar.
We set a focus cycle chain to swap the treeviews order for the keynav to
be more natural.
https://bugzilla.gnome.org/show_bug.cgi?id=690387
Unfortunately, this means duplicating the description attribute
to the text inside the KeyListEntry element, and marking the
KeyListEntry element as translatable by prepending "_".
<KeyListEntry
name="search"
_description="Search"/>
becomes:
<_KeyListEntry
name="search"
description="Search"
msgctxt="keybinding">
Search
</_KeyListEntry>
https://bugzilla.gnome.org/show_bug.cgi?id=689623
If the Pictures directory was renamed, or the directory name doesn't
match the current language, the dir name would have been wrong.
Enable translator to leave a space for the directory name in their
translation.
https://bugzilla.gnome.org/show_bug.cgi?id=685605
Both the compose key and the 3rd level chooser are common and useful
enough to expose in the control center.
Since these shortcuts are a small pre-defined set of only modifier
keys we present them in combo cell renderers.
https://bugzilla.gnome.org/show_bug.cgi?id=682069
Metacity/Mutter no longer have conditional shortcuts depending on
the number of workspaces, so there is no need to monitor the
num-workspaces settings (and reload all keybindings).
https://bugzilla.gnome.org/show_bug.cgi?id=663431
Keyboard shortcut definitions could specify a condition to determine
whether it should be shown in the UI or not. This was only used by
Metacity/Mutter, to make the visibility of some shortcuts depend on
the number of workspaces. However, as workspaces are now managed
dynamically in GNOME 3, the frequent changes to the list of shortcuts
have become rather confusing, so a fixed list of shortcuts is used now.
With the only consumer of conditional shortcuts gone, there's no reason
to keep the feature around.
https://bugzilla.gnome.org/show_bug.cgi?id=663431
We shouldn't need to select the "Custom Shortcuts" section
of the keyboard shortcuts before the add button is made sensitive.
Make it sensitive all the time, and switch to the section as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=662253
Right now, if both KeyList and KeyListEntry contain a schema element,
the (global) one of the list wins. This makes it rather cumbersome
to mix keys of different schemas in a single list, as rather than
using a default schema and specifying a different one where necessary,
every key needs its own schema element.
A brief IRC discussion suggests that the current precedence didn't
trigger any particular issues before, and neither should changing
it - so do this to support above case.
https://bugzilla.gnome.org/show_bug.cgi?id=653685
