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.

Mike Griese (@zadjii-msft)

Mike Griese (@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!)

If we did that, we could also put the splits in it...!

can we add right click context menus to menu flyouts?

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>

Damn, yea let's do that. ez.

Mike Griese (@zadjii-msft)

Sure Mike Griese (@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

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:

terminal/src/cascadia/TerminalControl/TermControl.cpp

Lines 3386 to 3404 in ce60bf2

    
           void TermControl::_showContextMenuAt(const til::point& controlRelativePos) 
        
           { 
        
               Controls::Primitives::FlyoutShowOptions myOption{}; 
        
               myOption.ShowMode(Controls::Primitives::FlyoutShowMode::Standard); 
        
               myOption.Placement(Controls::Primitives::FlyoutPlacementMode::TopEdgeAlignedLeft); 
        
               myOption.Position(controlRelativePos.to_winrt_point()); 
        
               // The "Select command" and "Select output" buttons should only be 
        
               // visible if shell integration is actually turned on. 
        
               const auto shouldShowSelectCommand{ _core.ShouldShowSelectCommand() }; 
        
               const auto shouldShowSelectOutput{ _core.ShouldShowSelectOutput() }; 
        
               SelectCommandButton().Visibility(shouldShowSelectCommand ? Visibility::Visible : Visibility::Collapsed); 
        
               SelectOutputButton().Visibility(shouldShowSelectOutput ? Visibility::Visible : Visibility::Collapsed); 
        
               SelectCommandWithSelectionButton().Visibility(shouldShowSelectCommand ? Visibility::Visible : Visibility::Collapsed); 
        
               SelectOutputWithSelectionButton().Visibility(shouldShowSelectOutput ? Visibility::Visible : Visibility::Collapsed); 
        
               (_core.HasSelection() ? SelectionContextMenu() : 
        
                                       ContextMenu()) 
        
                   .ShowAt(*this, myOption);

but instead of a "control-relative position", use CoreWindow::GetForCurrentThread().PointerPosition(). That's my thought at least.

Mike Griese (@zadjii-msft)

Mike Griese (@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?

I may take a stab at this if nobody is working it.

Which alignment do we want? I can show screenshots of all of them if you'd want to see them all

I kinda like this one.

Do we have a preference on which Icon we use for the LUA shield?

Or this guy?

Add support for running profiles from Add tab menu as admin without a…

Navigation Menu

Repository navigation

Launch elevated Terminal profile without a keyboard #14517

Description of the new feature/enhancement

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	void TermControl::_showContextMenuAt(const til::point& controlRelativePos)
	{
	Controls::Primitives::FlyoutShowOptions myOption{};
	myOption.ShowMode(Controls::Primitives::FlyoutShowMode::Standard);
	myOption.Placement(Controls::Primitives::FlyoutPlacementMode::TopEdgeAlignedLeft);
	myOption.Position(controlRelativePos.to_winrt_point());

	// The "Select command" and "Select output" buttons should only be
	// visible if shell integration is actually turned on.
	const auto shouldShowSelectCommand{ _core.ShouldShowSelectCommand() };
	const auto shouldShowSelectOutput{ _core.ShouldShowSelectOutput() };
	SelectCommandButton().Visibility(shouldShowSelectCommand ? Visibility::Visible : Visibility::Collapsed);
	SelectOutputButton().Visibility(shouldShowSelectOutput ? Visibility::Visible : Visibility::Collapsed);
	SelectCommandWithSelectionButton().Visibility(shouldShowSelectCommand ? Visibility::Visible : Visibility::Collapsed);
	SelectOutputWithSelectionButton().Visibility(shouldShowSelectOutput ? Visibility::Visible : Visibility::Collapsed);

	(_core.HasSelection() ? SelectionContextMenu() :
	ContextMenu())
	.ShowAt(*this, myOption);

Launch elevated Terminal profile without a keyboard #14517

Description

Description of the new feature/enhancement

Activity

zadjii-msft commented on Dec 9, 2022

237dmitry commented on Dec 9, 2022

DHowett commented on Dec 9, 2022

DHowett commented on Dec 9, 2022

zadjii-msft commented on Dec 9, 2022

DHowett commented on Dec 9, 2022

zadjii-msft commented on Dec 9, 2022

10 remaining items

michalnpl commented on Apr 21, 2023

zadjii-msft commented on May 17, 2023

michalnpl commented on May 25, 2023

jamespack commented on Jul 8, 2023

jamespack commented on Jul 8, 2023

jamespack commented on Jul 8, 2023

jamespack commented on Jul 8, 2023

jamespack commented on Jul 8, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions