Mutter supports the 'Above_Tab' fake keysym that refers to the key
that is physically located above the tab key. It is used in the default
shortcut of the "Switch windows of an application" action.
As gtk_accelerator_parse() doesn't recognize the keysym, we display
the shortcut incorrectly as "disabled", and it is not taken into account
for conflict resolution.
Address this by translating binding that contains the 'Above_Tab' string
to bindings where the string is replaced with each possible keysym that
corresponds to the fixed keycode of KEY_GRAVE + 8.
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/581
The instructions label says:
Press Esc to cancel or Backspace to reset the keyboard shortcut.
but the Backspace key set the shortcut to be empty, and disables the
feature. Reset is achieved clicking the button to the right handside of
the shortcut in the main window, and is only visible when the shortcut
isn't set to the default value.
Recent versions of Gettext are able to translate several formats
that are used in GNOME applications. This patch migrates from
Intltool to Gettext by using meson's i18n features.
https://bugzilla.gnome.org/show_bug.cgi?id=787588
With the old shell gone, there is no need to work around cut off panel
names (bug #647087). As it stands now, it only confuses translators
(invisible characters are hard to, well, see).
https://bugzilla.gnome.org/show_bug.cgi?id=792629
Meson is a build system focused on speed an ease of use, which
helps speeding up the software development. This patch adds meson
support along autotools.
https://bugzilla.gnome.org/show_bug.cgi?id=785414
Ensure that the vertical spacing inside each panel is similar.
This makes the transition between each panel smoother and makes
the control center feel more cohesive.
Settings panels are given 32px above and below their content
and 32px vertical space between major sections. 12px space is
placed below headings.
Bluetooth, displays and printers are not addressed.
https://bugzilla.gnome.org/show_bug.cgi?id=786384
For shortcuts that support multiple bindings, the disabled state is
expressed as an empty list rather than a list with a single empty
element. While the latter certainly works as expected as far as the
actual keybinding is concerned, the shortcut will show up as modified
even if it is disabled by default. Explicitly setting bindings to the
empty list when a shortcut is disabled fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=784620
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
For shortcuts that support more than one binding, we currently simply
ignore all but the first. This makes some sense as we only expose a
single binding in the UI anyway, however it means that any extra
bindings are not taken into account for conflict resolution. In order
to address this in the future, start tracking all bindings of an item.
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
Some shortcuts allow multiple bindings for the same actions, which
we mainly use to keep supporting old settings when changing defaults.
Multiple bindings are not exposed in the interface though, so when
changing a shortcut with multiple bindings, we previously only updated
the first one and left additional bindings untouched. This is confusing
however, precisely because additional bindings are not shown in the
UI - for instance, this makes it impossible to actually disable
such a shortcut completely. The less confusing option is to clear
any additional bindings when changing a shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=673078
Filtering on the name currently only matches the string as a whole,
not individual words as expected, for instance "home fo" and "ho fo"
should both match "Home Folder".
https://bugzilla.gnome.org/show_bug.cgi?id=784357
The Keyboard shortcut editor dialog gives no clue on how
to disable a shortcut, and users were confused by this
lack of information.
Fix that by informing the user about the Backspace role
when editing a shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=777401
When managing the keyboard shortcuts, the user might want
to check for keybindings based on their accelerators, not
only their names. Currently, however, the Keyboard panel
only supports searching for the keybinding description.
Fix that by also considering the normalized keybinding
accelerator when performing the search.
https://bugzilla.gnome.org/show_bug.cgi?id=772565
