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

[george-tsiros]

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.

[zadjii-msft]

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:

• [Settings]: Keyboard focus is not jumping on first control of the opened page. #13829
• [Settings - Startup]: Keyboard focus is going on 'Startup' heading which is a non-interactive control. #13020
• [Terminal> Actions]: Keyboard Focus did not jump inside 'Add New Actions' pop-up when user activate 'Add new' button. #12053
• [Settings] : User have to navigate through 'Open JSON file' control every time, While navigating in the 'Settings' window. #11964

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?

[george-tsiros]

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.

[zadjii-msft]

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.

[lhecker]

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. 🙂

[DHowett]

Note that doing this will probably break Windows Update.

[DHowett]

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. 😄

[bzzrak]

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

[george-tsiros]

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

[bzzrak]

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.