==31571== 288 bytes in 24 blocks are definitely lost in loss record 18,138 of 19,290
==31571== at 0x484086F: malloc (vg_replace_malloc.c:380)
==31571== by 0x4AF77A8: g_malloc (gmem.c:106)
==31571== by 0x4A4119: variant_get_key_combos (cc-keyboard-item.c:475)
==31571== by 0x4A41FD: settings_get_key_combos (cc-keyboard-item.c:498)
==31571== by 0x4A46BE: cc_keyboard_item_load_from_gsettings (cc-keyboard-item.c:574)
==31571== by 0x4A5BBB: append_section (cc-keyboard-manager.c:315)
==31571== by 0x4A605D: append_sections_from_file (cc-keyboard-manager.c:431)
==31571== by 0x4A6766: reload_sections (cc-keyboard-manager.c:568)
==31571== by 0x4A6D68: cc_keyboard_manager_load_shortcuts (cc-keyboard-manager.c:707)
==31571== by 0x4A2FA4: cc_keyboard_shortcut_dialog_init (cc-keyboard-shortcut-dialog.c:841)
==31571== by 0x4A7A288: g_type_create_instance (gtype.c:1929)
==31571== by 0x4A61CAC: g_object_new_internal (gobject.c:1945)
This commit includes all the changes that seem to be necessary for
CcKeyboardItem to be used for dealing with multiple keybindings, without
(yet) changing the user interface to expose this.
The `primary_combo` and `binding` fields of `CcKeyboardItem` are
removed, in favor of the existing `key_combos`. No combination is
"primary", since all of them can now be seen and changed equally.
We treat `CcKeyboardItem.key_combos` as a set, that a combo can be added
to or removed from. Though it continues to be represented as a `GList`,
instead of a `GHashTable`, to preserve ordering.
A lot of the keyboard panel code relied on the assumption that only one
combo can be set for each setting, so this required a variety of
miscellaneous changes.
Mutter supports the 'Above_Tab' fake keysym that refers to the key
that is physically located above the tab key. It is used in the default
shortcut of the "Switch windows of an application" action.
As gtk_accelerator_parse() doesn't recognize the keysym, we display
the shortcut incorrectly as "disabled", and it is not taken into account
for conflict resolution.
Address this by translating binding that contains the 'Above_Tab' string
to bindings where the string is replaced with each possible keysym that
corresponds to the fixed keycode of KEY_GRAVE + 8.
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/581
For shortcuts that support multiple bindings, the disabled state is
expressed as an empty list rather than a list with a single empty
element. While the latter certainly works as expected as far as the
actual keybinding is concerned, the shortcut will show up as modified
even if it is disabled by default. Explicitly setting bindings to the
empty list when a shortcut is disabled fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=784620
For shortcuts that support more than one binding, we currently simply
ignore all but the first. This makes some sense as we only expose a
single binding in the UI anyway, however it means that any extra
bindings are not taken into account for conflict resolution. In order
to address this in the future, start tracking all bindings of an item.
https://bugzilla.gnome.org/show_bug.cgi?id=673078
We currently store keyval, keycode and mask that make up a particular
key combo separately. However as we want to consider multiple bindings
for a single item, it makes more sense to combine them in a dedicated
struct type.
https://bugzilla.gnome.org/show_bug.cgi?id=673078
Some shortcuts allow multiple bindings for the same actions, which
we mainly use to keep supporting old settings when changing defaults.
Multiple bindings are not exposed in the interface though, so when
changing a shortcut with multiple bindings, we previously only updated
the first one and left additional bindings untouched. This is confusing
however, precisely because additional bindings are not shown in the
UI - for instance, this makes it impossible to actually disable
such a shortcut completely. The less confusing option is to clear
any additional bindings when changing a shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=673078
When comparing the keyboard shortcut's default and current
values, we double-check what kind of variant the default
value is, but don't check that for the user value.
This ends up throwing lots of variant-related warnings, as
the user value may not be a plain string.
Fix that by checking the variant types both for the user and
the default value of the shortcut's settings.
https://bugzilla.gnome.org/show_bug.cgi?id=769310
In order to simplify the porting to the new UI, the
reverse item functionality was removed. Now that all
the necessary code landed, it is time to bring it back.
This patch adds back the ability to manage reverse items.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
The current keyboard item API does not track whether the
keyboard shortcut is the default value or not. In order to
properly implement the Reset operation, the keyboard item
must receive this API and ideally handle it internally.
This patch adds the necessary API to CcKeyboardItem to track
whether the shortcut is the default value or not.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
This fixes:
==5944== 64,392 bytes in 4,223 blocks are definitely lost in loss record 16,020 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 0x144981DC: g_variant_get_strv (gvariant.c:1572)
==5944== by 0x48FA45: settings_get_binding (cc-keyboard-item.c:369)
==5944== by 0x48FA9D: binding_changed (cc-keyboard-item.c:384)
==5944== by 0x141C3E2F: g_cclosure_marshal_VOID__STRINGv (gmarshal.c:1794)
==5944== by 0x141BFBE3: _g_closure_invoke_va (gclosure.c:864)
==5944== by 0x141DA3E7: g_signal_emit_valist (gsignal.c:3292)
==5944== by 0x141DB55F: g_signal_emit (gsignal.c:3439)
==5944== by 0x13EDC81D: g_settings_real_change_event (gsettings.c:386)
https://bugzilla.gnome.org/show_bug.cgi?id=756762
It contains a strdup'ed string, but it's overwritten without being freed
first from cc_keyboard_item_load_from_gsettings_path() and
cc_keyboard_item_load_from_gsettings().
This fixes:
==5944== 976 bytes in 64 blocks are definitely lost in loss record 15,439 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 0x144981DC: g_variant_get_strv (gvariant.c:1572)
==5944== by 0x48FA45: settings_get_binding (cc-keyboard-item.c:369)
==5944== by 0x48FDDD: cc_keyboard_item_load_from_gsettings (cc-keyboard-item.c:438)
==5944== by 0x489EB7: append_section (keyboard-shortcuts.c:249)
==5944== by 0x48ADF6: append_sections_from_file (keyboard-shortcuts.c:578)
==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)
https://bugzilla.gnome.org/show_bug.cgi?id=756762
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
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
In order to handle shortcuts which can be reversed (for example,
super-space and shift-super-space to switch input methods
forward/backward), we are going to add new attributes to the xml files
describing the keyboard shortcuts to show in the panel.
This commit is a first step towards that and adds the notion of
'reverse' items to CcKeyboardItem.
We will then indicate in the xml description files that
'switch-input-source' is reversed by 'switch-input-source-backward' and
that 'switch-input-source-backward' reverses 'switch-input-source'.
https://bugzilla.gnome.org/show_bug.cgi?id=731618
Metacity/Mutter stores keybindings as string array to support multiple
bindings per action. Even though multiple bindings are not exposed in
the UI, support keybindings stored as string array by getting/setting
the first element of the array.
https://bugzilla.gnome.org/show_bug.cgi?id=653613
Move most of the horrible GConf monitoring code to a separate
GObject(-ish). While quite ugly, it's not as bad as the code that
used to be there before.
Also fix the setting of KeyEntry->model (or CcKeyboardItem->model now)
to be the correct model (eg. the shortcut model rather than the section
model)
