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
The Reset button, according to the mockups, should be placed
at the right side (left on rtl) of the shortcut label. Also,
rather than a plain string, the button should use a symbolic
icon for 'edit-clear' action.
This patch moves and updates the Reset button to match the
mockups.
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
The current button to reset shortcuts is represented by the
'x' icon, which induces the user to think this is a remove
button rather then a reset button.
Fix that by using edit-clear-symbolic icon to represent the
reset action.
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
Gtk+ changed again the behavior of the scrolled window,
fixing the weird height issue but introducing a new issue
where the keyboard shortcut list doesn't expand horizontally
nor allocates the correct size vertically.
Fortunately, this is easily solvable with the newly introduced
GtkScrolledWindow:propagate-natural-width and -height
properties.
Fix the misbehavior by setting the new properties to sane
values.
https://bugzilla.gnome.org/show_bug.cgi?id=769314
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
Based on the latest mockups, the Keyboard panel would
benefit from a search functionality.
This patch add all the necessary UI and functions to
make the search work. Worth noticing that the current
implementation still doesn't work with search-as-you-type,
which'll be addressed on a future fix.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
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 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
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
After porting the shortcuts management entirely to
GtkListBox, the current treeview is not necessary
anymore.
This patch removes the shortcuts treeview and all
the related functions, and separates the treeviews
from the underlying models.
https://bugzilla.gnome.org/show_bug.cgi?id=769063
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
