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

Add support for inheriting and overriding another profile's settings #3818

Open
krisavi opened this issue Dec 3, 2019 · 12 comments
Open

Add support for inheriting and overriding another profile's settings #3818

krisavi opened this issue Dec 3, 2019 · 12 comments
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal.
Milestone

Comments

@krisavi
Copy link

krisavi commented Dec 3, 2019

Description of the new feature/enhancement

I would like to make 2 profiles for same WSL, But as I tested, then you cannot put different GUID to make a duplicate with changes. I guess it is something to do with having same GUID and generator approach for the WSL using source field does not let you to have multiple GUIDs for same profile.

Proposed technical implementation details (optional)

One way would be to let you have different name field for the same GUID and treat them different not merging settings.
Other one I see is to have generator make a guid GUID to a group of terminals with same source, but then have subitem that could have multiple choices.
Then to have a submenu for each terminal profile based on it that basically could have custom generated GUID. If there is only one subprofiles item, then it shows only one and not as a submenu.
Profiles.json then could be something like:

    {
      "guid": "{58ad8b0c-3ef8-5f4d-bc6f-13e4c00f2530}",
      "hidden": false,
      "source": "Windows.Terminal.Wsl",
      "subProfiles": [
        {
          "guid": "{58ad8b0c-bc6f-3ef8-5f4d-13e4c00f2531}",
          "name": "Debian Half Dark",
          "useAcrylic": true,
          "fontFace": "Fira Code",
          "acrylicOpacity": 0.2,
          "colorScheme": "One Half Dark",
          "padding": "0, 0, 0, 0",
        },
        {
          "guid": "{58ad8b0c-5f4d-bc6f-3ef8-13e4c00f2532}",
          "name": "Debian Light",
          "useAcrylic": true,
          "fontFace": "Cascadia Code",
          "acrylicOpacity": 0.2,
          "colorScheme": "One Half Light",
          "padding": "0, 0, 0, 0",
        }
      ]
    }
@krisavi krisavi added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Dec 3, 2019
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Dec 3, 2019
@DHowett-MSFT DHowett-MSFT changed the title Multiple profiles on same dynamic profile Add support for inheriting and overriding another profile's settings Dec 5, 2019
@DHowett-MSFT
Copy link
Contributor

Congrats - this is now the bug for adding support for inheriting and overriding another profile's settings. It's something we've talked about for the post-v1.0 timeframe.

@DHowett-MSFT DHowett-MSFT added this to Spec Needed ❓ in Specification Tracker via automation Dec 5, 2019
@DHowett-MSFT DHowett-MSFT added Area-Settings Issues related to settings and customizability, for console or terminal Product-Terminal The new Windows Terminal. labels Dec 5, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Dec 5, 2019
@DHowett-MSFT DHowett-MSFT removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Dec 5, 2019
@DHowett-MSFT DHowett-MSFT added this to the Terminal Backlog milestone Dec 5, 2019
@raworre
Copy link

raworre commented Jan 29, 2020

I'm looking around the issues here to see if there was anything documented about the feature I'm looking for. Wondering if my use case fits under "inheriting" as it's defined in this issue.

My use case is such that I would like to have the same background and font settings for all of my profiles. Currently I have to enter those fields in each profile like thus:

{
    "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
    "name": "Windows PowerShell",
    "commandline": "powershell.exe",
    "hidden": false,
    "fontFace": "Consolas",
    "fontSize": 10,
    "background": "#272935",
    "backgroundImage": "%SOURCE_ROOT%/images/mushroom_cloud.jpg",
    "backgroundImageOpacity": 0.1,
    "startingDirectory": "%SOURCE_ROOT%",
    "tabTitle": "PowerShell 5.1"
},
{
    "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
    "name": "cmd",
    "commandline": "cmd.exe",
    "hidden": false,
    "fontFace": "Consolas",
    "fontSize": 10,
    "background": "#272935",
    "backgroundImage": "%SOURCE_ROOT%/images/mushroom_cloud.jpg",
    "backgroundImageOpacity": 0.1,
    "startingDirectory": "%SOURCE_ROOT%",
    "tabTitle": "Windows Command Prompt"
}

I would like to be able to set a shared profile that looked something like below that could then be referenced as a parent in other profiles.

{
    "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bx}",
    "name": "Default Profile",
    "fontFace": "Consolas",
    "fontSize": 10,
    "background": "#272935",
    "backgroundImage": "$SOURCE_ROOT%/images/mushroom_cloud.jpg",
    "backgroundImageOpacity": 0.1,
    "startingDirectory": "%SOURCE_ROOT%"
},
{
    "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
    "name": "Windows PowerShell",
    "commandline": "powershell.exe",
    "hidden": false,
    "parentProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bx}",
    "tabTitle": "PowerShell 5.1"
},
{
    "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
    "name": "cmd",
    "commandline": "cmd.exe",
    "hidden": false,
    "parentProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bx}",
    "tabTitle": "Windows Command Prompt"
}

Just wanting to make sure this is the issue I want to watch for this behavior, if there is another issue encompassing this behavior, or if it already exists and I've completely missed it.

@DHowett-MSFT
Copy link
Contributor

@raworre I’ve got great news for you! We shipped defaults in 0.8; check out the docs!

@raworre
Copy link

raworre commented Jan 29, 2020

@DHowett-MSFT Giggity! Thanks for the quick reply! Absolutely loving the product so far.

@UsmanMohammad
Copy link

The one issue it doesn't solve is inheriting the icon, as I do have to manually set the icon for every Powershell Core terminal

@mikemklee
Copy link

Is there still no way to have multiple WSL profiles?

@DHowett-MSFT
Copy link
Contributor

{
"name": "my other ubuntu profile",
"commandline": "wsl -d Ubuntu",
"colorScheme": "Presumably the reason I added a second copy of ubuntu colors"
}

@DHowett-MSFT
Copy link
Contributor

DHowett-MSFT commented Apr 9, 2020

{
"name": "my other ubuntu profile",
"commandline": "wsl -d Ubuntu",
"colorScheme": "Presumably the reason I added a second copy of ubuntu colors",
"icon": "c:/path/to/literally/any/icon"
}

We've actually got a document explaining the cool settings you can use, if you're interested 😄. The docs entry point is a good place to start, but it does bury the lede a bit.

@mikemklee
Copy link

mikemklee commented Apr 9, 2020

@DHowett-MSFT Ah! What got me confused was the correct syntax for the path.

I knew that there is the //wsl$/Ubuntu/... for specifying wsl paths,
and that there is /mnt/c/... for spcifying window paths.

I did not know about the c:/... syntax.

I tried this: "icon": "/mnt/c/path/to/icon" but got confused because I kept getting an invalid icon path error.

Your solution worked like a charm! thank you!

Edit:
I get it now. Because Windows Terminal is running on the windows side, I need to specify my path in the windows syntax, not the WSL syntax... aha!

@saadanerdetbare
Copy link

As a comment to the idea OP posted, if this could be done with PS Core and adding support for having alternate $profile settings in the different profiles this would be cool

@DHowett-MSFT
Copy link
Contributor

As a comment to the idea OP posted, if this could be done with PS Core and adding support for having alternate $profile settings in the different profiles this would be cool

So for this one, at least, you can use $Env:WT_PROFILE_ID (which will always match your profile GUID) to set different settings in profile.ps1 for different WT profiles.

@saadanerdetbare
Copy link

saadanerdetbare commented May 3, 2020

So for this one, at least, you can use $Env:WT_PROFILE_ID (which will always match your profile GUID) to set different settings in profile.ps1 for different WT profiles.

Ok, didn't know there was a variable for the guid. So as per #4160 and #5490 just make a profile with commandline pwsh.exe and simply invoke $Env:WT_PROFILE_ID.ps1 from $profile

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal.
Projects
Specification Tracker
  
Spec Needed ❓
Development

No branches or pull requests

7 participants