terminal
terminal copied to clipboard
microsoft
Launch elevated Terminal profile without a keyboard
Description of the new feature/enhancement
Today, there is no way to launch an elevated Terminal profile end-to-end without the need to use a keyboard.
Even without a physical keyboard, the user flow is still the same with a on-screen keyboard:
- Launch Terminal
- Ctrl + Click the profile you want to open
This Feature Request proposes a way for a user to open an elevated Terminal profile without the need to use a keyboard. This is a very common Accessibility scenario. The user should be able to launch an elevated Terminal profile with just a touch screen and / or mouse.
For more details see: https://twitter.com/SBarizien/status/1599769771666391042
Were there any suggestions for how to do that?
The only thing I could think of was some default nested actions for opening a new elevated profile in the Command Palette. Trick here is the wording - we don't want to open a new window always, but we'll need to if the terminal isn't already elevated.
Maybe just "Open Elevated > {profiles}"?
As a workaround you can elevate current profile or execute command in elevated state with gsudo via UAC confirmation.
@zadjii-msft I thought of this, which is everyone's favorite UI:
It's a right-click menu item with a right-click menu. It also works with touch (touch-hold-release!)
I gave it a shot in XAML Studio!
<Rectangle Width="100" Height="100" Fill="Yellow">
<Rectangle.ContextFlyout>
<MenuFlyout>
<MenuFlyoutItem Text="First" />
<MenuFlyoutItem Text="Second">
<MenuFlyoutItem.ContextFlyout>
<MenuFlyout>
<MenuFlyoutItem Text="Well I'll Be..." />
</MenuFlyout>
</MenuFlyoutItem.ContextFlyout>
</MenuFlyoutItem>
</MenuFlyout>
</Rectangle.ContextFlyout>
</Rectangle>
I've got a kind of fix for it. The tasks in Jumplist do not support custom menus, AFAIK. But I added the context menu to the profiles flyout. However, the context menu is wrong-positioned, and I have trouble determining why. It works correctly with localization and elevation; just the positioning is off. I used BottomEdgeAlignedLeft on profileMenuItem and experimented with all combinations, always getting it off.
W E I R D. Xaml does have a tendency to do all sorts of weird stuff like that. Just recently I saw something weird like that with CommandBarFlyout where just switching to the Microsoft.UI.Xaml version (from Windows.UI.Xaml) magically fixed something.
@michalnpl any chance you've got a branch to share? Maybe I could take a look.
Sure @zadjii-msft here is the branch
Don't forget to regenerate resources (added items to .resw).
Interestingly Shift+F10 (shortcut to invoke context menu) opens the context menu in the right place while right-clicking on the item opens it completely misaligned.
@michalnpl Sorry this got lost in my list of open tabs 😅
I'm betting that it's something with
runAsAdminContextMenu.ShowAt(profileMenuItem);
Like, I'd hope that works. But I'd bet that XAML islands does something weird with flyouts like that. I know there were issues with DPI scaling of mouse events in XAML islands before, so I wouldn't be surprised here.
This might be a crazy idea, but I bet you could just manually ask XAML to show the flyout at the cursor position. Something like:
https://github.com/microsoft/terminal/blob/ce60bf290a1750c9cf00d4fbe35715d946748d76/src/cascadia/TerminalControl/TermControl.cpp#L3386-L3404
but instead of a "control-relative position", use CoreWindow::GetForCurrentThread().PointerPosition(). That's my thought at least.
@zadjii-msft No worries. I thought about it but abandoned the idea because it seems like this should be handled correctly by XAML, and I am also afraid I'll miss some edge cases, or it will not be future-proof if I handle it manually. The proposed code seems to be doing the correct thing but the framework is acting unexpectedly. Perhaps there is a way to have the XAML team look at this?
Which alignment do we want? I can show screenshots of all of them if you'd want to see them all