starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-24 16:05:21 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

the Terminal's system menu (alt+space) doesn't have keyboard accelerators #20254

New Issue
Open
opened 2026-01-31 07:08:09 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 07:08:09 +00:00
Owner
Copy Link

Originally created by @george-tsiros on GitHub (Jul 19, 2023).

Windows Terminal version

Windows build number

Other Software

Steps to reproduce

run it

Expected Behavior

I intentionally categorize this as a bug, not as a feature request.
Windows has had comprehensive keyboard navigation for more than two decades.
I do not know what happened, but recently everything is gone.
Open a context menu, no shortcuts. They take longer to appear, do fancy animations or whatever, but they are unusable without the mouse.
Same deal with this disaster here.
Try to use it without a mouse. Try to use all of it without a mouse and you will understand.

conhost: alt-space, Properties and P is underlined. It has a shortcut.
wt: alt-space, there is a Settings entry, but no shortcut. Why.

conhost: ctrl-tab, cycle through various settings tabs, as fast as the keyboard can send keypresses.
wt: we use tab. It changes the focus of the item selected. Tab to go down to the list of categories. Categories do not change: one must press return. Okay. Startup, press down, press enter, see "Interaction" tab. Press down, press enter, see "Appearance" tab. ... Where did the focus just go? Oh look, at the bottom of the window a new button has appeared. Now you have to hold up to get focus back where it should have been. Okay. Press enter on "Color schemes". Now focus has gone in the tab contents? Why? Escape does not go up the hierarchy. Did 4 shift-tab to get back at the list.
'Actions'. Moving focus up-down shows the pencil button, but there is no way to actually activate it. You have to use the mouse button. I mashed my entire keyboard. Nothing at all happened. The only two keys that do something are 'up' and 'down'.
No idea why we must, but we click the mouse. It's like I'm playing diablo all over again.

conhost: alt-space, p, ctrl-tab (as needed), press a letter/digit or alt+letter/digit and you've accessed or changed any available setting immediately. Any configuration option available to the user is 4(min) 8(max) keypresses away.

I'm not gonna sugarcoat it.
Your efforts and the sheer amount of work you have put are both astounding
But you are focusing so hard on features and fanciness that you've completely ignored usability
Keyboard navigation is not something you can tack-on after the fact. Yes, I see the Actions list. That, is not keyboard navigation.
Thank you for your time.

Actual Behavior

Impossible to use without a mouse.

Originally created by @george-tsiros on GitHub (Jul 19, 2023). ### Windows Terminal version - ### Windows build number - ### Other Software - ### Steps to reproduce run it ### Expected Behavior I intentionally categorize this as a bug, not as a feature request. Windows has had comprehensive keyboard navigation for more than two decades. I do not know what happened, but recently everything is gone. Open a context menu, no shortcuts. They take longer to appear, do fancy animations or whatever, but they are unusable without the mouse. Same deal with this disaster here. Try to use it without a mouse. Try to use *all* of it without a mouse and you will understand. conhost: alt-space, `Properties` and `P` is underlined. It has a shortcut. wt: alt-space, there is a `Settings` entry, but no shortcut. Why. conhost: ctrl-tab, cycle through various settings tabs, as fast as the keyboard can send keypresses. wt: we use tab. It changes the focus of the item selected. Tab to go down to the list of categories. Categories do not change: one must press return. _Okay_. Startup, press down, press enter, see "Interaction" tab. Press down, press enter, see "Appearance" tab. ... Where did the focus just go? Oh look, at the _bottom of the window_ a new button has appeared. Now you have to hold up to get focus back where it should have been. _Okay_. Press enter on "Color schemes". Now focus has gone _in_ the tab contents? Why? Escape does not go up the hierarchy. Did 4 shift-tab to get back at the list. 'Actions'. Moving focus up-down shows the pencil button, but there is no way to actually activate it. You _have_ to use the mouse button. I mashed my entire keyboard. Nothing at all happened. The only two keys that do something are 'up' and 'down'. No idea why we must, but we click the mouse. It's like I'm playing diablo all over again. conhost: alt-space, p, ctrl-tab (as needed), press a letter/digit or alt+letter/digit and you've accessed or changed any available setting immediately. _Any_ configuration option available to the user is 4(min) 8(max) keypresses away. I'm not gonna sugarcoat it. Your efforts and the sheer amount of work you have put are both astounding But you are focusing so hard on features and fanciness that you've completely ignored _usability_ Keyboard navigation is _not_ something you can tack-on after the fact. Yes, I see the Actions list. That, is not keyboard navigation. Thank you for your time. ### Actual Behavior Impossible to use without a mouse.
claunia added the Help WantedIssue-BugProduct-TerminalArea-Windowing labels 2026-01-31 07:08:09 +00:00
claunia commented 2026-01-31 07:08:10 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 19, 2023):

Thanks for the feedback!

I'm gonna try and boil this down to some specific cases, with a little less editorialization.

Group A - the Terminal's system menu (alt+space) doesn't have keyboard accelerators

  • conhost: alt-space, Properties and P is underlined. It has a shortcut.
  • wt: alt-space, there is a Settings entry, but no shortcut.

This is definitely a good catch, and something we should fix! We should make sure we've got a dedicated work item for this.

Group B - Tab navigation in the Settings UI is wonky

  • conhost: ctrl-tab, cycle through various settings tabs, as fast as the keyboard can send keypresses
  • wt: we use tab. It changes the focus of the item selected. Tab to go down to the list of categories.
    • Categories do not change: one must press return. Okay
    • Press down, press enter, see "Appearance" tab. ... Where did the focus just go?
      • Oh look, at the bottom of the window a new button has appeared. Now you have to hold up to get focus back where it should have been
    • Press enter on "Color schemes". Now focus has gone in the tab contents?
    • 'Actions'. Moving focus up-down shows the pencil button, but there is no way to actually activate it.

This is all good feedback, and pain points that we should fix. I think a lot of this is already tracked in various threads. For example, the query https://github.com/microsoft/terminal/issues?q=is%3Aissue+is%3Aopen+tab+focus+order has a bunch of the things you've mentioned here, or at least I think they are. Namely:

And surely, there are others. WinUI is certainly less optimized for pure keyboard navigation (you're right about the enter to select different nav view pages, and I don't know if accelerators on arbitrary controls are possible like they were with ComCtl)

I think we'd be happy to sort these all out. I think you've got a great handle on this particular scenario - mind filing individual bugs for each of these scenarios? That makes it a lot easier to track these down and sort them out. Giant conglomerations of complaints like this make it hard to track resolving the individual root causes.

I'd say we move this thread to tracking adding accelerators to the Terminal's system menu, and move the other SUI issues to other threads. Sound good?

@zadjii-msft commented on GitHub (Jul 19, 2023): Thanks for the feedback! I'm gonna try and boil this down to some specific cases, with a little less editorialization. ## Group A - the Terminal's system menu (`alt+space`) doesn't have keyboard accelerators > * conhost: alt-space, Properties and P is underlined. It has a shortcut. > * wt: alt-space, there is a Settings entry, but no shortcut. This is definitely a good catch, and something we should fix! We should make sure we've got a dedicated work item for this. ## Group B - Tab navigation in the Settings UI is wonky > * conhost: ctrl-tab, cycle through various settings tabs, as fast as the keyboard can send keypresses > * wt: we use tab. It changes the focus of the item selected. Tab to go down to the list of categories. > * Categories do not change: one must press return. _Okay_ > * Press down, press enter, see "Appearance" tab. ... Where did the focus just go? > * Oh look, at the bottom of the window a new button has appeared. Now you have to hold up to get focus back where it should have been > * Press enter on "Color schemes". Now focus has gone in the tab contents? > * 'Actions'. Moving focus up-down shows the pencil button, but there is no way to actually activate it. This is all good feedback, and pain points that we should fix. I think a lot of this is already tracked in various threads. For example, the query https://github.com/microsoft/terminal/issues?q=is%3Aissue+is%3Aopen+tab+focus+order has a bunch of the things you've mentioned here, or at least I think they are. Namely: * #13829 * #13020 * #12053 * #11964 And surely, there are others. WinUI is certainly less optimized for pure keyboard navigation (you're right about the <kbd>enter</kbd> to select different nav view pages, and I don't know if accelerators on arbitrary controls are possible like they were with ComCtl) I think we'd be happy to sort these all out. I think you've got a great handle on this particular scenario - mind filing individual bugs for each of these scenarios? That makes it a lot easier to track these down and sort them out. Giant conglomerations of complaints like this make it hard to track resolving the individual root causes. ---- I'd say we move this thread to tracking adding accelerators to the Terminal's system menu, and move the other SUI issues to other threads. Sound good?
claunia commented 2026-01-31 07:08:10 +00:00
Author
Owner
Copy Link

@george-tsiros commented on GitHub (Jul 19, 2023):

If "WinUI" is what i think it is and if you're using it for WT, i am afraid the project is dead in the water as far as keyboard navigation is concerned. Ultimately, i see 0 reason for WT - or any terminal emulator - having any sort of GUI on top of it: it is a terminal emulator. By design, the moment you open one, you imply that you're on a 9600 baud line with the OS through a serial port. Animations, colors, sounds, font smoothing, mouse, all straight out the window.
But that's just me.
Maybe it is too late, but the project should have been split in two, the emulator itself and the settings frontend.

@george-tsiros commented on GitHub (Jul 19, 2023): If "WinUI" is what i think it is and if you're using it for WT, i am afraid the project is dead in the water as far as keyboard navigation is concerned. Ultimately, i see 0 reason for WT - or any terminal emulator - having _any_ sort of GUI on top of it: it is a _terminal emulator_. By design, the moment you open one, you imply that you're on a 9600 baud line with the OS through a serial port. Animations, colors, sounds, font smoothing, mouse, all straight out the window. But that's just me. Maybe it is too late, but the project should have been split in two, the emulator itself and the settings frontend.
claunia commented 2026-01-31 07:08:10 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 19, 2023):

Ah. Well. That's a perfectly fine opinion to have. That's why we've got all the settings in a perfectly human readable settings.json file. If you want to, go ahead and just change the settings however you'd like straight up in that file. If you were a masochist, you could even attempt to build an exe that just included a comctl propsheet to edit that file.

In fact, the Terminal codebase is already split up into different layers that separate the actual terminal control from the rest of the app. In #6999, we're planning on shipping the TermControl all by itself. Once that's out, developers would be totally free to build whatever kind of UI they want on top of it.

@zadjii-msft commented on GitHub (Jul 19, 2023): Ah. Well. That's a perfectly fine opinion to have. That's why we've got all the settings in a perfectly human readable `settings.json` file. If you want to, go ahead and just change the settings however you'd like straight up in that file. If you were a masochist, you could even attempt to build an exe that just included a comctl propsheet to edit that file. In fact, the Terminal codebase is already split up into different layers that separate the actual terminal control from the rest of the app. In #6999, we're planning on shipping the TermControl all by itself. Once that's out, developers would be totally free to build whatever kind of UI they want on top of it.
claunia commented 2026-01-31 07:08:10 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jul 19, 2023):

FYI you can technically use OpenConsole from our portable .zip releases and replace your system's conhost.exe with it. If you then set the UseDx value under the HKEY_CURRENT_USER\Console to DWORD 2 then you'll effectively get the entire Windows Terminal code base but with the old conhost UI.

Just now I've learned that sfpcopy is actually a public tool that ships with Windows 10 IoT Core, so I guess it's actually not a problem if a upload it on the internet. It's technically required to use when you replace system files (If anyone reads this: Don't ever manually replace existing System32 files. They're hardlinked around and you break Windows if you do this unless you use something like sfpcopy.) So anyways, here's my script that does this automatically (PowerShell, requires elevation for sfpcopy). Edit: Removed out of caution. It may break a user's system. 🙂

@lhecker commented on GitHub (Jul 19, 2023): FYI you can technically use `OpenConsole` from our portable .zip releases and replace your system's conhost.exe with it. If you then set the `UseDx` value under the `HKEY_CURRENT_USER\Console` to `DWORD` `2` then you'll effectively get the entire Windows Terminal code base but with the old conhost UI. Just now I've learned that `sfpcopy` is actually a public tool that ships with Windows 10 IoT Core, so I guess it's actually not a problem if a upload it on the internet. It's technically required to use when you replace system files (If anyone reads this: Don't ever manually replace existing System32 files. They're hardlinked around and you break Windows if you do this unless you use something like `sfpcopy`.) So anyways, here's my script that does this automatically (PowerShell, requires elevation for `sfpcopy`). Edit: Removed out of caution. It may break a user's system. 🙂
claunia commented 2026-01-31 07:08:10 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 19, 2023):

Note that doing this will probably break Windows Update.

@DHowett commented on GitHub (Jul 19, 2023): Note that doing this will probably break Windows Update.
claunia commented 2026-01-31 07:08:11 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 19, 2023):

Ultimately, i see 0 reason for WT - or any terminal emulator - having any sort of GUI on top of it: it is a terminal emulator.

Unfortunately, we do need to have menus and buttons and stuff. There's a surprising amount of interface in even the oldest terminal emulators (like xterm's three hidden right-click menus!).

Moving the settings editor to a separate application will not remove its dependency on WinUI, so it's somewhat moot. 😄

@DHowett commented on GitHub (Jul 19, 2023): > Ultimately, i see 0 reason for WT - or any terminal emulator - having any sort of GUI on top of it: it is a terminal emulator. Unfortunately, we do need to have menus and buttons and stuff. There's a surprising amount of interface in even the oldest terminal emulators (like xterm's three hidden right-click menus!). Moving the settings editor to a separate application will not remove its dependency on WinUI, so it's somewhat moot. :smile:
claunia commented 2026-01-31 07:08:11 +00:00
Author
Owner
Copy Link

@bzzrak commented on GitHub (Aug 10, 2023):

In the alt+space menu you can just press S. If there's no underline, the initial letter is used as the accelerator.

@bzzrak commented on GitHub (Aug 10, 2023): In the alt+space menu you can just press S. If there's no underline, the initial letter is used as the accelerator.
claunia commented 2026-01-31 07:08:11 +00:00
Author
Owner
Copy Link

@george-tsiros commented on GitHub (Aug 11, 2023):

@bzzrak did you try that? Because if I do as you suggest, the window starts moving.

@george-tsiros commented on GitHub (Aug 11, 2023): @bzzrak did you _try_ that? Because if I do as you suggest, the window starts moving.
claunia commented 2026-01-31 07:08:11 +00:00
Author
Owner
Copy Link

@bzzrak commented on GitHub (Aug 11, 2023):

I would assume the S gets taken up by "Size" or something. My system isn't in English so the letter S is only used by "Settings", and it works.

@bzzrak commented on GitHub (Aug 11, 2023): I would assume the S gets taken up by "**S**ize" or something. My system isn't in English so the letter S is only used by "Settings", and it works.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Windowing Help Wanted Issue-Bug Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#20254
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?