The way shortcuts in mutter/gnome-shell work is that it looks up the
keycode that generates the shortcut keyval at the lowest shift level and
then checks if all the modifiers match. This does not work for shortcuts
that for example include "dollar" to represent "<Shift>4", because on
some keyboards/layout there is a separate dollar key key with its own
keycode. This would be at a lower shift level than "<Shift>4".
By always translating such shortcuts to "<Shift>number", we make sure
the resulting shortcut will work in the shell and is closer to what the
user likely intended the shortcut to be, because numbers are usually
assigned to things that can be enumerated, such as workspaces or
favorite applications.
This also special cases the num-row key on layouts such as AZERTY, where
the number is the shifted keyval, to always prefer the number. Due to
the way the shell interprets these shortcuts, they still work and by
always using numbers they work across different layouts.
This change also fixes that pressing "<Shift><Super>4" was turned into
"<Shift><Super>dollar", which effectively included the "<Shift>" twice.
Fixes: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1528
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.
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
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
The accelerator formatting method itself is copied from
GtkCellRendererAccel, and will be used throughout the code
to format the accelerators just like they used to be before
moving to the listbox.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
To allow a much easier porting to the new layout, the keyboard
panel is now a template class. That has various implications on
the code organization:
- The keyboard-shortcuts.c was responsible for filling the shortcuts.
Because it relied on the GtkBuilder of the panel, most of its code
was moved to the CcKeyboardPanel class.
- The unused code from the keyboard panel class had to be removed in
order to make it work again.
- All the hash tables and widgets are now part of the CcKeyboardPanel
structure.
- The interface elements have a single entry point.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
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
