==25729== 1,058 (40 direct, 1,018 indirect) bytes in 1 blocks are definitely lost in loss record 20,104 of 20,657
==25729== at 0x484086F: malloc (vg_replace_malloc.c:380)
==25729== by 0x4AF77A8: g_malloc (gmem.c:106)
==25729== by 0x4B0F1E4: g_slice_alloc (gslice.c:1072)
==25729== by 0x4B09060: UnknownInlinedFun (gsequence.c:1609)
==25729== by 0x4B09060: g_sequence_insert_before (gsequence.c:527)
==25729== by 0x4ED2FE7: gtk_list_store_insert (gtkliststore.c:1271)
==25729== by 0x4A5DCE: append_section (cc-keyboard-manager.c:363)
==25729== by 0x4A605D: append_sections_from_file (cc-keyboard-manager.c:431)
==25729== by 0x4A6766: reload_sections (cc-keyboard-manager.c:568)
==25729== by 0x4A6D33: cc_keyboard_manager_load_shortcuts (cc-keyboard-manager.c:706)
==25729== by 0x4A2FA4: cc_keyboard_shortcut_dialog_init (cc-keyboard-shortcut-dialog.c:841)
==25729== by 0x4A7A288: g_type_create_instance (gtype.c:1929)
==25729== 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.
This appears to be largely vestigial code from a time when a GtkTreeView
was used here. It is very confusing, because someone reading the code
expects this to be critical to what's displayed on the screen, but it
isn't.
If I understand correctly, the only place this was still useful for
something was in `cc_keyboard_manager_remove_custom_shortcut()`, to check
that the CcKeyboardItem is valid. If I understand, this is a sanity
check that should never fail, so this seems unnecessary, and I've
removed it.
If that check is actually important, it would be better to have a
`GHashTable` of custom shortcuts, which should be simpler and clearer.
`sections_store` should similarly be removed/replaced. It seems to only
be needed in `add_shortcuts()`. But that seems like it can't just be
removed, so I haven't changed that yet.
While we are now able to find conflicts for a particular key combo in
non-primary bindings, in the case of resetting a shortcut we need to
check all key combos in case the shortcut itself has multiple bindings
by default.
https://bugzilla.gnome.org/show_bug.cgi?id=673078
We now have everything in place to extend the uniqueness check to
consider all bindings of an item rather than just the first one.
With this it is finally possible to set Alt+Tab as binding for
"Switch windows" without keeping the hidden Alt+Tab binding of the
"Switch applications" shortcut ...
https://bugzilla.gnome.org/show_bug.cgi?id=673078
Comparing masks is currently part of the early checks we perform to
determine that two bindings are different. There's some convenience
in that, however logically the mask is part of the binding, and
separating the mask check from comparing the "rest" of the binding
makes it harder to extend the comparison to consider multiple bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=673078
When comparing keys for uniqueness, we currently apply various tests to
check whether shortcuts are different, until we decide that we found a
conflict if none of the tests passed. That approach is a bit weird for
shortcuts that have a reverse item - when comparing a binding to two
different shortcuts, it should always be different from at least one of
them, so there should never be a conflict for any reversible shortcuts.
The reason it does work anyway is that reverse items usually only differ
in modifiers, which is_shortcut_different() currently doesn't consider at
all. We are about to change that however, so refactor the code to set the
conflicting item as soon as we find a match rather than as fall-through.
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
From a Coverity scan:
panels/keyboard/cc-keyboard-manager.c:208: unreachable: Since the loop
increment "i++;" is unreachable, the loop body will never execute more
than once.
This seems like a logic thinko introduced in commit
3207fe97ec . In practice it was unlikely
to be a problem since we don't have repeated shortcut gsettings key
names in all our KeyListEntries files.
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
Following the proposed mockups, the shortcut list must
have the ability to reset modified to non-default shortcuts
right from the listbox.
After adding the necessary API in CcKeyboardItem, adding
the user-visible elements to enable that is easy.
To make that happen, add a button that resets the
keyboard shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
The collision detection code was removed in commit a0a155884e
as the cleanup was happening because the previous code was closely
tied to the user interface components.
Because that code wasn't appliable to the new listbox UI, it was
temporarily removed.
This patch re-adds this feature to work with the new code orgazination.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
Instead of having CcKeyboardPanel managing both UI and backend code,
factor the backend code to a new CcKeyboardManager class and drop
backend management from the panel itself.
The new backend class handles the loading, creation and removal and
search of keyboard shortcuts. It also resolves reversible shortcuts
when searching.
This patch moves the code to this new class, and updates the rest of
the Keyboard panel to use it instead.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
