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
When creating a new keyboard shortcut, the Add button gets
sensitive when all the fields are valid. If the user tries
to create a new shortcut right after closing the shortcut
editor dialog, the Add button is still sensitive even with
invalid custom fields.
Fix that by making the Add button sensitive whenever we
finish editing the new custom shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
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
While using the Keyboard shortcut editor dialog under
Wayland, the user receives a <Meta> key even when this
key isn't present in the physical keyboard nor in the
keymap.
This is probably the result of Wayland inheriting from
X's xkb.
To work around that, simply filter out this modifier.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
The current CcKeyboardPanel used to manage keyboard
editing through GtkCellRendererAccel, which was replaced
when we moved to use a GtkListBox. Because of that,
the ability to edit shortcuts is now missing.
Re-add shortcut editing capabilities through a new dialog,
which is done according to the latest mockups available.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
