Follow-up from "Keyboard panel re-design"
The following discussions from !785 (merged) should be addressed:
-
@ids1024 started a discussion: (+2 comments) Some further notes on the dropdown for input switching keybinding:
The mockup includes options like
ctrl+shift
that aren't possible bindings (to my knowledge) under Mutter's keybinding system, but are possible usingxkb-options
.(Such
xkb-options
can currently be found under "Additional Layout Options" in Gnome Tweaks.)The behavior of layout switching through that mechanism is not quite the same. Using the current keybinding that works through Mutter, there's a popup similar to alt-tab switching. No such thing appears when it is done through
xkb-options
. I'm not sure if anything else differs.We would also want to not have the binding set through both systems. So I suppose
switch-input-source
inorg.gnome.desktop.wm.keybindings
should be changed to default to[]
. But then, that would leave anyone who changed it with the value they had set, but no GUI method to reset it. So would we want to remove that gsettings key entirely?And conversely, I suppose since the binding exists by default,
xkb-options
in theorg.gnome.desktop.input-sources
should have the binding added to its default value.So as I understand it, there are some possible concerns with implementing this, and likely changes to things other than Gnome Control Center. But feel free to correct me.
-
@ids1024 started a discussion: (+2 comments) Weird. I've been able to build outside Gnome Builder on my system, and the CI build seems to be passing, but I can reproduce this with Gnome Builder. It also displays this:
../panels/keyboard/cc-xkb-modifier-dialog.c:318:3: warning: implicit declaration of function ‘hdy_action_row_set_title’; did you mean ‘hdy_action_row_set_subtitle’? [-Wimplicit-function-declaration]
Not sure why
hdy_action_row_set_subtitle
would exist, but nothdy_action_row_set_title
. Forcing it to build with the git submodule of libhandy, instead of the system version, seems to fix it though. I guess this is some kind of issue with the Gnome SDK, or with Gnome Control Center's meson configuration...@aday Anyway, at least as a temporary solution for testing, I've pushed a commit that seems to make it build in Gnome Builder.
-
@maria-komarova started a discussion: (+1 comment) Per our conversation during the Gnome design team call, here are a few instances when one would use multiple key bindings for the same action:
-
The shortcuts that use Arrow keys. Some might like to use alternative arrow keys, like the ones used in Vim, along with the regular Arrow keys. Same goes to AWSD used in gaming. It doesn’t seem ergonomic but I have read descriptions of people specifically looking to use those keys as alternative arrow keys. Using alternative Arrow keys in this case might be valuable for users who primarily navigate their desktop with the keyboard. Moving window to a different monitor is one of those shortcuts. In case of Pop!_OS we also use Arrow keys as part of the shortcuts for navigating and managing windows as part of the tiling.
-
Users who use Numpad along with the regular keyboard. For example, to use PgUp, PgDown or Home/End along with the same keys on the main keyboard. “Switch workspaces”, “Move window to a workspace” use PgUp, PgDown.
-
Gnome currently has some cases with multiple combinations bound to the same action. See the full list here: https://gist.github.com/ids1024/dc77543876b75659bc7a20bc21184c41
One example is “Switch to workspace up/down” shortcuts already have Ctrl+Alt+Up/Down as alternative key bindings to Super + PgUp/Down. But they are not exposed in the UI it seems. (https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/blob/master/schemas/org.gnome.desktop.wm.keybindings.gschema.xml.in)
Another example is older shortcuts like Alt+Tab (same as Super+Tab), Super+Down (Alt+F5) that are currently bound to the same action but not exposed. If one tries to use, let’s say, Alt+Tab right now, the system gives a regular conflict message, saying that the combination is currently used by Switch applications and if you replace it, Switch applications would be disabled. But in reality, there is another binding for Switch applications. So there is a bit of awkwardness there. Maybe that can be simply cleared with messaging, I am not sure. But right now this is the only way to know this key binding is used for switching applications.
- This might be more of a consideration than an actual use of multiple keys. Currently Media keys can be used for the keyboard shortcuts. They are bound to both
XF86AudioPlay
andctrl+XF86AudioPlay
because keyboards are inconsistent. But if anyone decides to use a Media key as a shortcut along with Ctrl for something else, the system won’t warn them about the conflict which might result in an awkward behavior. Having multiple key bindings per action would help in those conflict situations.
-
-
@maria-komarova started a discussion: (+1 comment) Thanks for looking at the multiple bindings question @aday.
Some follow up thoughts.
- We were thinking about the scenario of just changing the direction keys as a set and therefore changing the shortcuts that use them. But there is still a need to expose the bindings with alternative direction keys in the UI next to the shortcuts that use them.
- The numpad keys are all considered different keys. They do not automatically work as End, Home, PgUp, Pg Down currently. Maybe this is more of the question that it should work and there are just some technical limitations of why they don't. But right now they are called differently when you try setting bindings using them in the Control Center.
- I think the issue I see is more about the messaging. When the warning message says that Switch Application shortcut will be disabled if one uses Alt+Tab for something else. This is probably a minor issue. But on the other hand, exposing multiple bindings in the UI might help with having a consistent way of approaching those kinds of situations. There are quite a few shortcuts with legacy bindings it seems.
- This is indeed an awkward one. I am not sure what would be best for those.
-
@robert.ancell started a discussion: (+2 comments) @ids1024 correct, this feature will have to be merged into GNOME 3.40 as we're now getting close to the 3.38 release. Please do split changes off into smaller MRs, as they are much easier to review and can be landed before the final feature is complete.
-
@aday started a discussion: (+1 comment) I've taken another look at the branch today. In general it looks really good to me, although I think there are maybe two outstanding issues.
First: search in the keyboard shortcut dialog pans to the right, rather than showing the results in the current location. That's non-standard for GNOME. Maybe not a dealbreaker, but it would good to fix it at some point.
Second, the bigger issue - the form of the Region & Language panel still needs to be resolved. The main issue at the moment is that the formats preview is shown in the panel, and then again in the formats dialog. It's not the most terrible thing in the world, but it's not exactly elegant either.
I recently did some design work to try and figure out a path forward here. The approach I came up with is to remove the formats preview from the panel, and put language selection there instead. This would be dependent on changing the logic of language selection, to only show installed languages rather than every possible language (as covered in #202). That would obviously involve additional work.
The shorter term easy fix would be to remove the format preview from the panel, and move some of the text from the dialogs to the panel, to help bulk it out:
It's a bit empty, but it could be OK for now?
-
@ids1024 started a discussion: (+1 comment) Now that 3.38 is branched, and some of the refactoring changes here have already been merged, I've updated this branch.
@aday I've added the descriptions to the region panel, and removed the sliding transition on search results.
-
@bertob started a discussion: (+8 comments) I built the latest commit, quick design review:
When first opening this dialog the size/proportions are a bit odd. A few things that could help:
- add a few pixels of vertical padding to each row, to make them the same height as the shortcut rows in the categories
- make the dialog a bit less tall (maybe 100px or so)
- maybe make the dialog a bit wider (50px or so)
Inside the category pages, I would
- right-align the shortcuts
- increase the left padding on the shortcut rows to match the one from the rows on the overview list
After adding the first custom shortcut there's an odd list row at the top, which looks like it's maybe a leftover of the previous design. I don't think we need any of this apart from the add button, which could just be a
+
button at the bottom of the list. -
@bertob started a discussion: (+2 comments) It'd also be cool to use HdyDeck for the sub-views inside the dialog, so you can swipe to go back.
-
@ids1024 started a discussion: (+2 comments) I updated it to use
HdyActionRow
, which makes the row sizing more consistent, and changed the add custom shortcuts button to just a row with "+".The alignment of the shortcuts is unchanged, but keeping it like the previous design seems like a neutral default that needn't block merging, but could be changed later if it's clear something else is preferred.
I guess the height/width of the dialog may need adjustment, but that's fairly straightforward.
Those are all the concerns I can think of at the moment.
-
@ids1024 started a discussion: (+2 comments) I've rebased on master fixing conflicts, and right aligned with the reset button not taking up space when hidden. I removed the
default-height
property. Without it, the dialog ends up this size: