Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring back old Windows ways of launching Cmd #8113

Closed
ck2510 opened this issue Oct 30, 2020 · 5 comments
Closed

Bring back old Windows ways of launching Cmd #8113

ck2510 opened this issue Oct 30, 2020 · 5 comments
Labels
Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Resolution-Won't-Fix We're just really obstinate about this. There's probably a good reason.

Comments

@ck2510
Copy link

ck2510 commented Oct 30, 2020

Description of the new feature/enhancement

In early versions of Windows10 it was still possible to launch Cmd from Windows Explorer context menu and also to place an icon into the Windows Explorer "QuickAccessToolbar". Then at some point it was decided to promote PowerShell and those possibilities where removed and strange registry hacks emerged to control the behavior of cmd vs. powershell involving keys like HideBasedOnVelocityId and ShowBasedOnVelocityId, see also [1].

Now there a strange hacks with questionable security to bring back the old UX or workarounds with less integration as shell commands.

[1]
https://superuser.com/questions/1201988/how-do-i-change-open-with-powershell-to-open-with-command-prompt-when-shift

Proposed technical implementation details (optional)

Encourage Windows to again give user the choice between PowerShell and Cmd and have both with equal level of integration in the system, as it is still the case for Win-X menu.

Edit: removed mistake of referring to command line, actually Windows Explorer context menu was meant
Edit2: fixed link

@ck2510 ck2510 added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Oct 30, 2020
@ghost ghost added Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Oct 30, 2020
@WSLUser
Copy link
Contributor

WSLUser commented Oct 30, 2020

This will never happen. CMD is still available for use. When right click selection in Explorer is brought back for Windows Terminal, you'll get this behavior if you set CMD as your default (eventually a selection between profiles will also be added). CMD is not equal to Powershell and never will be. You are heavily encouraged to use Powershell, which continues to get support in the form of Powershell Core.

@DHowett
Copy link
Member

DHowett commented Oct 30, 2020

No. You can configure whatever you like on your own machine; we are not stopping you.

@DHowett DHowett closed this as completed Oct 30, 2020
@DHowett
Copy link
Member

DHowett commented Oct 30, 2020

You are free to put shortcuts to CMD anywhere on your system that you like. Put 100 of them on your taskbar, type cmd into the address bar, change the default profile of Terminal to CMD. We only control one of these surfaces.
I do not understand why you have cited this repository, the repository on which you filed this issue, as a hack?

@DHowett DHowett added the Resolution-Won't-Fix We're just really obstinate about this. There's probably a good reason. label Oct 30, 2020
@ck2510
Copy link
Author

ck2510 commented Oct 30, 2020

Sorry my mistake with the link I can understand that the request is outside the scope of this project. Anyway I have a hard time to understand MS strategy here. This project promotes CMD/terminal, Windows tries to push it out from UX.

@zadjii-msft
Copy link
Member

I think there's a bit of a misunderstanding here - cmd != console.

cmd.exe is a shell, like powershell or bash.

These commandline clients can run attached to a console. Whenever you open cmd.exe, the window that you're actually seeing is conhost.exe, the Console. That's the window that serves all console application on Windows, including cmd and powershell.

This is the repo for both the Console and the Windows Terminal. Both their codebases live in this repo. The Console is getting occasional maintenance, and the Terminal is actively maintained and updated frequently. What we're not doing is actively promoting cmd. The official party line is "if you want a modern shell, that receives updates, use PowerShell".

ghost pushed a commit that referenced this issue Oct 10, 2022
It turns out that the negative margin for the progress ring is causing
the clipping in case the tab title gets too long:

https://github.com/microsoft/terminal/blob/43dbbd590fa4b46c37e9970415f8150d3c399598/src/cascadia/TerminalApp/TabHeaderControl.xaml#L18-L27

The negative margin was introduced in #8113 because the progress ring is
supposed to replace the tab icon but the `TabView` still reserves space
even if no icon is set (see
#8133 (comment)).
However, it is not actually the `TabView` reserving space even when
there is no icon, but a workaround for a crash in the
`IconPathConverter` that returns a `BitmapIconSource` with a `nullptr`
source instead of a `nullptr` `IconSource`:

https://github.com/microsoft/terminal/blob/43dbbd590fa4b46c37e9970415f8150d3c399598/src/cascadia/TerminalSettingsModel/IconPathConverter.cpp#L143-L154

The workaround in `IconPathConverter` could probably be removed as I did
not find any instance where it is still used in a way that could trigger
the mentioned crash, but I did not dare to just remove it as I do not
know enough about the code by far. Hence, I opted to just locally
instantiate the `IconSource` with a `nullptr` directly in `TerminalTab`.

Fixes #8910
DHowett pushed a commit that referenced this issue Oct 13, 2022
It turns out that the negative margin for the progress ring is causing
the clipping in case the tab title gets too long:

https://github.com/microsoft/terminal/blob/43dbbd590fa4b46c37e9970415f8150d3c399598/src/cascadia/TerminalApp/TabHeaderControl.xaml#L18-L27

The negative margin was introduced in #8113 because the progress ring is
supposed to replace the tab icon but the `TabView` still reserves space
even if no icon is set (see
#8133 (comment)).
However, it is not actually the `TabView` reserving space even when
there is no icon, but a workaround for a crash in the
`IconPathConverter` that returns a `BitmapIconSource` with a `nullptr`
source instead of a `nullptr` `IconSource`:

https://github.com/microsoft/terminal/blob/43dbbd590fa4b46c37e9970415f8150d3c399598/src/cascadia/TerminalSettingsModel/IconPathConverter.cpp#L143-L154

The workaround in `IconPathConverter` could probably be removed as I did
not find any instance where it is still used in a way that could trigger
the mentioned crash, but I did not dare to just remove it as I do not
know enough about the code by far. Hence, I opted to just locally
instantiate the `IconSource` with a `nullptr` directly in `TerminalTab`.

Fixes #8910

(cherry picked from commit 21a9c55)
Service-Card-Id: 86209056
Service-Version: 1.16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Resolution-Won't-Fix We're just really obstinate about this. There's probably a good reason.
Projects
None yet
Development

No branches or pull requests

4 participants