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
==31571== 120 bytes in 8 blocks are definitely lost in loss record 17,034 of 19,290
==31571== at 0x484086F: malloc (vg_replace_malloc.c:380)
==31571== by 0x4AF77A8: g_malloc (gmem.c:106)
==31571== by 0x4D9816A: gtk_accelerator_name (gtkaccelgroup.c:1577)
==31571== by 0x4A82D1: setup_custom_shortcut (cc-keyboard-shortcut-editor.c:364)
==31571== by 0x4A92DF: cc_keyboard_shortcut_editor_key_press_event (cc-keyboard-shortcut-editor.c:745)
In the shortcut editor, the "Replace" button is shown instead of "Set"
or "Add" when there is a collision. But this executes the same code as
"Set", so when adding a shortcut, it doesn't actually work.
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
After successfully editing a default shortcut (and making sure the
"Set" button is sensitive), if the user clicks the '+' row to create
a new custom shortcut, the "Add" button is sensitive even with all
fields empty.
Fix that by ensuring the "Add" button is always insensitive whenever
we add a custom shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=777842
The current shortcut editor state is managed by setting and
comparing the page name directly, making the code look more
complicated than it should.
Fix this by introducing the concept of pages, and using this
to set and get the current shortcut editor dialog state.
https://bugzilla.gnome.org/show_bug.cgi?id=777845
After introducing the reset button to match the mockups [1], the
shortcut editor dialog had some issues exposed. This is visible
e.g. when the user tries to edit a custom shortcut's name and
the shortcut is disabled.
This happens because we assume there is always a shortcut set.
When we open the dialog to edit a custom shortcut, however, nothing
is actually set, and we end up saving the disabled shortcut when
editing the shortcut's name or command.
Fix that by initializing the shortcut's accelerators when editing a
shortcut, and correcting the logic to validate the shortcut.
[1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/system-settings/keyboard/keyboard-wires.pnghttps://bugzilla.gnome.org/show_bug.cgi?id=777845
When adding a custom shortcut, the header mode was set to be
only "Cancel". Per mockups, the "Add" button should also be
visible but insensitive.
Fix that by correctly setting the header mode on creation mode.
https://bugzilla.gnome.org/show_bug.cgi?id=777824
When creating a new shortcut, we currently assume the entries are
sensitive and just show the dialog. This, however, may not be, for
example after previously canceling the editing of a custom shortcut,
leading to a state where the name and command entries are insensitive.
Fix that by always making sure the entries are sensitive when
setting the dialog to creation mode.
https://bugzilla.gnome.org/show_bug.cgi?id=777824
When canceling the editing of a custom shortcut, the "Edit" button
keeps pressed, causing inconsistencies when editing future custom
events.
To reproduce that:
- Open a custom shortcut and click "Edit"
- Start typing the new shortcut; the "Cancel" button will appear
- *Before* completing the new shortcut, click "Cancel"; the dialog will hide
- Open a custom shortcut again; the "Edit" button is still toggled
Fix that by properly untoggling the Edit button when cancelling
the editing.
https://bugzilla.gnome.org/show_bug.cgi?id=777824
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
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
