search

microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
95.93k stars 8.35k forks source link

Allow for custom profiles when running as admin vs user #3637

Open tmmuessig opened 5 years ago

tmmuessig commented 5 years ago

Description of the new feature/enhancement

Having the ability to create different profiles, can be a great visual clue as to what you are doing, or where you are doing it at, e.g dev vs production. The same can be said about running as an administrator vs a regular user. As an admin I can potentially make damaging changes to a system, while as a normal user, I would not have the permissions. Having the ability to not only customize a profile, but have a separate profile that would load when it is detected that I launched the terminal as administrator would be a handy visual clue that I can do something potentially destructive. A red background for admin, or a green background as a user for example.

Proposed technical implementation details (optional)

Add the ability to create a different profile section for running the terminal when I right click and select "Run As Administrator" vs just normally launching the Terminal as a normal user.

zadjii-msft commented 5 years ago

This I shockingly don't hate.

We'd need some way to convey that this profile is only visible when elevated (or only visible when un-elevated). Further, this setting would need to be clear that it's not running the profile as admin, just that it's only visible when the Terminal is elevated.

I know Sublime Text has the notion of context for keybindings, where you can define some arbitrary queries for when keybindings apply. Maybe a similar style could be applied? Though that does seem like overkill for a feature that really only has three states.

Related: #632 (but not a dupe)

evankanderson commented 4 years ago

(I was just looking for this today, wanted to add a +1)

tmmuessig commented 3 years ago

@zadjii-msft - Has there been any update (thought, consideration, testing) to this?

ianabrown commented 3 years ago

If we're trying to gather requirements for this that feel like they'd fit within the existing setup, I'd request:

Somewhat selfishly, these two would satisfy what I'd want from this feature - in my case, I'd go for a red tab color and a default profile of Powershell when elevated, but command prompt and normal tab color when not - but it also seems like it might address the requirements of the OP too?

tmmuessig commented 3 years ago

@ianabrown - This absolutely would fit my requirements, and I love the idea of the defaultsWhenElevated "section" of the configuration. That way I can keep 99% of my settings (tab color, background, fonts, etc.), but only change those settings if 1. I am running as Admin, and 2, only if the defaultsWhenElevated are configured.

The way I see it is as follows:

Launch Terminal as Admin

        "defaults": {
            // Put settings here that you want to apply to all profiles
            "fontFace": "Cascadia Code PL",
            "fontSize": 10,
            "padding": "8, 8, 8, 8",
            "cursorShape": "bar",
            "backgroundImage": "ms-appdata:///Local/NonAdminWallpaper.jpg",
        },
        "defaultsWhenElevated": {
            // Put settings here that you want to apply while running as admin. Settings here will override any defaults defined
            "backgroundImage": "ms-appdata:///Local/AdminWallpaper.jpg",
            "tabColor":"Red"
        },
0xabu commented 2 years ago

IMO this is more important now that Win11's Win+X A launches Windows Terminal in admin mode and not PowerShell/CMD. At a minimum, maybe we could just have a different defaultProfile when elevated?

(My default profile is a WSL shell, but for elevation I almost always want something native.)

zadjii-msft commented 2 years ago

That's actually a really good point. Here's my showerthought spec for this, which I'm thinking is the most minimal way we could do this

\

Two settings changes:

I reopened #8311 for tracking scheme and other settings changes to existing profiles, since that wasn't really addressed in #8455. I may type these bits up as an addendum to that spec.

What I'd be "afraid" of is the same problem from #8345 where there's a combinatorial explosion of flags, but that's actually mitigated a bit by these just being flags, and not "keys that are basically sets of flags"

Warning Yea we rejected that spec. It wasn't comprehensive enough.

tmmuessig commented 1 year ago

@zadjii-msft - Just wondering if there has been any more consideration for implementing this?

zadjii-msft commented 1 year ago

Not really. It's still just kinda parked on the backlog - we'd definitely accept it as a community contribution. Alas, I don't think we're about to get to this any time soon.

I'll tag it up for discussion to see if the rest of the team is cool with the pseudo-spec I posted above. If there's consensus, I can write up a walkthrough of what I'd do to implement this.

May want to xref #13929 when we have that discussion.

Note: for discussion We add the above two settings. At least the profile.hidden changes seems easier. The elevatedDefaultProfile one is still suspect to the combinatorial problem. For example: #13284. That's another variable.

Discussion conclusion: the tiny little spec there was definitely not sufficient. We'll come up with something more wholistic through #11111

michael-hawker commented 5 months ago

I liked @carlos-zamora idea mentioned in #11111 where there's just a completely separate config json file for admin mode. Maybe there could just be another setting toggle to enable that behavior?

Then there's just two independent settings files, one used for non-admin and one for admin. Then users can just customize all their settings when Terminal is elevated? They'll basically just work in isolation. Maybe there's some infobar if the setting it turned on that reminds them when terminal is elevated that the settings are for elevated only?