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
From a Coverity scan:
panels/keyboard/cc-keyboard-manager.c:208: unreachable: Since the loop
increment "i++;" is unreachable, the loop body will never execute more
than once.
This seems like a logic thinko introduced in commit
3207fe97ec . In practice it was unlikely
to be a problem since we don't have repeated shortcut gsettings key
names in all our KeyListEntries files.
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
As described in the proposed mockups [1], the Keyboard panel
should have a Reset All button above the list of shortcuts that
allows the user to quickly reset all the shortcuts to their
default keybinding. The current implementation, however, lacks
this button.
Fix that by adding a "Reset All" button, and implementing the
reset all action. A message dialog is shown in order to confirm
the action, and custom shortcuts are not reset (unless the conflict
with the default keybinding of another standard 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=777840
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
