Feature Request: Start with multiple tabs open #1039

@afalk42 commented on GitHub (May 14, 2019):

@mdtauk there is already the ability to add multiple profiles to the profiles.json configuration file, but you can currently only specify one of them as your defaultProfile, which is why you can only start with one tab

@afalk42 commented on GitHub (May 14, 2019): @mdtauk there is already the ability to add multiple profiles to the profiles.json configuration file, but you can currently only specify one of them as your defaultProfile, which is why you can only start with one tab

claunia commented

@mdtauk commented on GitHub (May 14, 2019):

@mdtauk there is already the ability to add multiple profiles to the profiles.json configuration file, but you can currently only specify one of them as your defaultProfile, which is why you can only start with one tab

Yes I am aware of the profiles.json, and I am sure that will get a GUI in the settings for the app soon.

But you could change defaultProfile to have a list of profiles I suppose.

Maybe in the GUI there could be an option in each profile's customisation page:

[✔] Include this profile when starting Windows Terminal

@mdtauk commented on GitHub (May 14, 2019): > @mdtauk there is already the ability to add multiple profiles to the profiles.json configuration file, but you can currently only specify one of them as your defaultProfile, which is why you can only start with one tab Yes I am aware of the profiles.json, and I am sure that will get a GUI in the settings for the app soon. But you could change defaultProfile to have a list of profiles I suppose. Maybe in the GUI there could be an option in each profile's customisation page: [✔] Include this profile when starting Windows Terminal

claunia commented

@Kryptos-FR commented on GitHub (May 14, 2019):

I'd rather have those settings spit into two different files: profiles.json is portable between machine (and maybe users), while the default(s) could be user dependent (so defaultProfiles.json?).

@Kryptos-FR commented on GitHub (May 14, 2019): I'd rather have those settings spit into two different files: `profiles.json` is portable between machine (and maybe users), while the default(s) could be user dependent (so `defaultProfiles.json`?).

claunia commented

@zadjii-msft commented on GitHub (May 14, 2019):

Lets try to reel things in before the discussion gets out of hand - a couple things mentioned here deserve their own threads to discuss them.

perhaps it could remember the last session before the app was closed?

This is now #766

I'd rather have those settings spit into two different files: profiles.json is portable between machine (and maybe users), while the default(s) could be user dependent (so defaultProfiles.json?).

This is #641

I'm all for adding a setting for which tabs/panes & profiles to open with, though we'll probably need to keep "default profile" as a single profile GUID.

@zadjii-msft commented on GitHub (May 14, 2019): Lets try to reel things in before the discussion gets out of hand - a couple things mentioned here deserve their own threads to discuss them. > perhaps it could remember the last session before the app was closed? This is now #766 > I'd rather have those settings spit into two different files: profiles.json is portable between machine (and maybe users), while the default(s) could be user dependent (so defaultProfiles.json?). This is #641 I'm all for adding a setting for which tabs/panes & profiles to open with, though we'll probably need to keep "default profile" as a single profile GUID.

claunia commented

2026-01-30 22:14:43 +00:00

@glen-84 commented on GitHub (May 22, 2019):

I don't think that this is necessary if #766 is implemented. It would be more than covered by session resumption features.

There's only one small edge case that I can think of:

Open window 1 with the 3 profiles that you're interested in.
Open window 2 with another profile that isn't so important.
Instead of closing window 2 and then 1, or using the "Exit" option to close both windows, close window 1 and then window 2.
When the session is resumed, only window 2 would be restored.

However:

It's not something that would happen often.
If support is added for window history, window 1 could be reopened from "Recently closed windows".

@afalk42 Would #766 support your use case?

@glen-84 commented on GitHub (May 22, 2019): I don't think that this is necessary if #766 is implemented. It would be more than covered by session resumption features. There's only one small edge case that I can think of: 1. Open window 1 with the 3 profiles that you're interested in. 2. Open window 2 with another profile that isn't so important. 3. Instead of closing window 2 and then 1, or using the "Exit" option to close both windows, close window 1 and then window 2. 4. When the session is resumed, only window 2 would be restored. However: 1. It's not something that would happen often. 2. If support is added for window history, window 1 could be reopened from "Recently closed windows". @afalk42 Would #766 support your use case?

claunia commented

@afalk42 commented on GitHub (May 22, 2019):

Hi @glen-84
Yes, this would be sufficient for my narrow use case.
But think about the analogy with multi-tabbed web browsers for a moment: there we typically give users the choice of starting a new session either with a fixed list of tabs, or with the same tabs that were available when the browser was closed.
So in an ideal world I would love to see both #756 and #766 implemented.
But if time constraints only allow for one, then #766 appears to be more useful to more users due to simplicity of usage.

@afalk42 commented on GitHub (May 22, 2019): Hi @glen-84 Yes, this would be sufficient for my narrow use case. But think about the analogy with multi-tabbed web browsers for a moment: there we typically give users the choice of starting a new session either with a fixed list of tabs, or with the same tabs that were available when the browser was closed. So in an ideal world I would love to see both #756 and #766 implemented. But if time constraints only allow for one, then #766 appears to be more useful to more users due to simplicity of usage.

claunia commented

2026-01-30 22:14:43 +00:00

@WSLUser commented on GitHub (May 29, 2019):

so in an ideal world I would love to see both #756 and #766 implemented.

I would second this. Whichever is the easier to tackle first should get out the door but the terminal is becoming a browser for CLI stuff basically (we have tabs just like an actual browser and can select different "websites" aka console apps) and thus needs to act as one accordingly.

@WSLUser commented on GitHub (May 29, 2019): > so in an ideal world I would love to see both #756 and #766 implemented. I would second this. Whichever is the easier to tackle first should get out the door but the terminal is becoming a browser for CLI stuff basically (we have tabs just like an actual browser and can select different "websites" aka console apps) and thus needs to act as one accordingly.

claunia commented

2026-01-30 22:14:43 +00:00

@gregchamblin commented on GitHub (Jul 3, 2019):

I would think the easiest way to implement this, and feel free to correct me if I am thinking to simplistically here, is to make defaultProfile a list, and iterate over it. If that is one tab or twelve.

I could also see a usefulness instead of opening with multiple profiles, just make one Hotkey open multiple profiles. Then, I could setup multiple (hidden?) profiles for each project I am working on. To me, this method would be preferred.

@gregchamblin commented on GitHub (Jul 3, 2019): I would think the easiest way to implement this, and feel free to correct me if I am thinking to simplistically here, is to make defaultProfile a list, and iterate over it. If that is one tab or twelve. I could also see a usefulness instead of opening with multiple profiles, just make one Hotkey open multiple profiles. Then, I could setup multiple (hidden?) profiles for each project I am working on. To me, this method would be preferred.

claunia commented

@joe-mills commented on GitHub (Jul 17, 2019):

I would like a higher level grouping like a terminal workspace that reflects the project I'm working on in VS Code e.g. I would open a tab for dotnet API, ubuntu Angular, dotnet STS server etc.
It seems like that's the kind of thing that could be developed as a Windows Terminal extension and installed from the terminal extension store.

@joe-mills commented on GitHub (Jul 17, 2019): I would like a higher level grouping like a terminal workspace that reflects the project I'm working on in VS Code e.g. I would open a tab for dotnet API, ubuntu Angular, dotnet STS server etc. It seems like that's the kind of thing that could be developed as a Windows Terminal extension and installed from the terminal extension store.

claunia commented

@WSLUser commented on GitHub (Jul 17, 2019):

@joe-mills that sounds like a separate feature request and would require Windows Terminal to implement an API similar to VS Code to enable extensions. This is doable but effort. I wouldn't even consider trying to implement that until we at least have a stable v1 out the door. You'd constantly be having to change the way the API behaves until everything is settled down enough to know, "this is our baseline".

@WSLUser commented on GitHub (Jul 17, 2019): @joe-mills that sounds like a separate feature request and would require Windows Terminal to implement an API similar to VS Code to enable extensions. This is doable but _effort_. I wouldn't even consider trying to implement that until we at least have a stable v1 out the door. You'd constantly be having to change the way the API behaves until everything is settled down enough to know, "this is our baseline".

claunia commented

@joe-mills commented on GitHub (Jul 17, 2019):

@WSLUser yes I guess I was just agreeing that profile groups would be nice but thinking its probably too early to start adding these kind of quality of life features in before v1.

It seemed like the extensions community was a great proving ground for features in vscode and the terminal app does lend itself to some kind of extension management system. Really enjoying the terminal right now though.

@joe-mills commented on GitHub (Jul 17, 2019): @WSLUser yes I guess I was just agreeing that profile groups would be nice but thinking its probably too early to start adding these kind of quality of life features in before v1. It seemed like the extensions community was a great proving ground for features in vscode and the terminal app does lend itself to some kind of extension management system. Really enjoying the terminal right now though.

claunia commented

@DHowett-MSFT commented on GitHub (Oct 8, 2019):

So I suppose this was discussed before in #1043, though there doesn't seem like there's a unique issue for it, so congratulations, this is now the thread :)

There are probably a bunch of things we'd want to consider as part of a comprehensive solution here.

What if someone wants to open the terminal with multiple tabs (what you've already discussed above)

What about with multiple panes, in various different split configurations? How would we set that?

Perhaps the user wants to auto-launch multiple windows? In different locations, etc.

Obviously, any solution for the above three should not preclude any of the others. Users would want to be able to specify multiple windows, each with their own tabs, and with tabs that might have any number of panes.

Would we want this multi-launch behavior to only happen on first launch, or every Terminal launch?

With the nesting behavior you have above, what if someone had a recursive loop, where one profile A specified launching profile B, and B specified launching A? That would theoretically cause an infinite loop - do we allow that?

(I'm sure there's more I'm missing here)

This is certainly a problem that's feasible from an engineering standpoint, but due to the complexity of specifying these scenarios, I'd want a spec written first to try and think through the edge cases before we start working on the code.

from @zadjii-msft in https://github.com/microsoft/terminal/issues/3037#issuecomment-537940097

@DHowett-MSFT commented on GitHub (Oct 8, 2019): > > > So I suppose this was discussed before in #1043, though there doesn't seem like there's a unique issue for it, so congratulations, this is now the thread :) > > There are probably a bunch of things we'd want to consider as part of a comprehensive solution here. > > * What if someone wants to open the terminal with multiple tabs (what you've already discussed above) > > * What about with multiple panes, in various different split configurations? How would we set that? > > * Perhaps the user wants to auto-launch multiple _windows_? In different locations, etc. > > * Obviously, any solution for the above three should not preclude any of the others. Users would want to be able to specify multiple windows, each with their own tabs, and with tabs that might have any number of panes. > > * Would we want this multi-launch behavior to only happen on _first_ launch, or _every_ Terminal launch? > > * With the nesting behavior you have above, what if someone had a recursive loop, where one profile A specified launching profile B, and B specified launching A? That would theoretically cause an infinite loop - do we allow that? > > * (I'm sure there's more I'm missing here) > > > This is certainly a problem that's feasible from an engineering standpoint, but due to the complexity of specifying these scenarios, I'd want a [spec](https://github.com/microsoft/terminal/blob/master/doc/specs/spec-template.md) written first to try and think through the edge cases before we start working on the code. _from @zadjii-msft in https://github.com/microsoft/terminal/issues/3037#issuecomment-537940097_

claunia commented

@ItsMeBrianD commented on GitHub (Oct 24, 2019):

To throw in my two cents on the comment above, I found this thread looking for a way to launch 3 tabs in a single shortcut, while opening another with a separate shortcut. For my dev environment I need to have 3+ cli programs running [klink (kitty cli), iisexpress, and ngrok], and I've just configured these to each be separate tabs, it would be great if I could create a shortcut to open those three, and another to open my WSL tab, so I don't have to choose one or the other.

@ItsMeBrianD commented on GitHub (Oct 24, 2019): To throw in my two cents on the comment above, I found this thread looking for a way to launch 3 tabs in a single shortcut, while opening another with a separate shortcut. For my dev environment I need to have 3+ cli programs running [klink (kitty cli), iisexpress, and ngrok], and I've just configured these to each be separate tabs, it would be great if I could create a shortcut to open those three, and another to open my WSL tab, so I don't have to choose one or the other.

claunia commented

@danielniccoli commented on GitHub (Nov 12, 2019):

@gregchamblin Yeah, this would suffice in my opinion.

Simply something like that:

What if someone wants to open the terminal with multiple tabs (what you've already discussed above)

What about with multiple panes, in various different split configurations? How would we set that?

Perhaps the user wants to auto-launch multiple windows? In different locations, etc.

Would we want this multi-launch behavior to only happen on first launch, or every Terminal launch?

I think that renaming the setting defaultProfile to defaultProfiles and have them accept a list of profiles should be the first thing to to. This should be a quick fix (said the amateur programmer 😛).

For bullet points two and three, I think we should move a few terms around. What today is considered a profile, I would rename to shell. Then I would use profiles to combine multiple shells. In a profile you could either define all of those things mentioned in the bullet points, or tell Terminal to open the last session.

The dropdown should be changed to display profiles, but also shells. Shells should be hidable from the list, in case they are only used in profiles.

With the nesting behavior you have above, what if someone had a recursive loop, where one profile A specified launching profile B, and B specified launching A? That would theoretically cause an infinite loop - do we allow that?

With the quick concept I described above, this would not be possible as a shell is just the pure look and feel of exactly the described shell. You would not be able to nest a shell in a shell, that wouldn't make sense anymore. And profiles cannot be nested in themselves.

A quick example

{
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "defaultProfile": "{11111111111}",
    "globals": {
        "initalCols": 180,
        "initialRows": 30
    },
    "shells": [
        {
            "guid": "{...}",
            "hidden": false,
            "name": "cmd",
            "commandline": "cmd.exe"
        },
        {
            "guid": "{...}",
            "hidden": false,
            "name": "Ubuntu"
        },
        {
            "guid": "{...}",
            "hidden": true, // Only used in a profile.
            "name": "Ubuntu Dark Theme",
            "colorScheme": "Ubuntu Dark Theme"
        }
    ]
    "profiles": [
        {
            "guid": "{11111111111}",
            "name": "My default profile",
            // If *layout and openLastSession are used in the same profile, throw error
            "openLastSession": true
        },
        {
            // Opens one Terminal with multiple tabs
            "guid": "{...}",
            "name": "Side by side"
            "shells": [
                "cmd",
                "Ubuntu"
            ]
        },
        {
            // Opens one Terminal with multiple tabs. Layout:
            // ╔═══════╦═══╗
            // ║       ║   ║
            // ║       ╠═══╣
            // ║       ║   ║
            // ║       ║   ║
            // ╚═══════╩═══╝
            "guid": "{...}",
            "name": "Side by side"
            "shells": [
                "cmd",
                "Ubuntu",
                "Ubuntu Dark Theme"
            ]
            // If *layout and openLastSession are used in the same profile, throw error
            // Instead of tabLayout, windowLayout can be used to open multiple windows instead of tabs
            "tabLayout": {
                // In the tabLayout (windowLayout) the defined shells would be used in order.
                // shell:cmd
                "split": "vertical",
                "ratio": [70, 30]
                {
                    // shell:Ubuntu,Ubuntu Dark Theme
                    "split": horizontal,
                    "ratio": [40,70]
                }
            }
        },
        {
            // Opens one Terminal with multiple tabs. Layout:
            // ╔═════╦══╦══╗
            // ║     ║  ║  ║
            // ╚═════╩══╩══╝
            "guid": "{...}",
            "name": "Side by side"
            "shells": [
                "cmd",
                "Ubuntu",
                "Ubuntu Dark Theme"
            ]
            // If *layout and openLastSession are used in the same profile, throw error
            "tabLayout": {
                // In the tabLayout (windowLayout) the defined shells would be used in order.
                // shell:cmd,Ubuntu,Ubuntu Dark Theme
                "split": "vertical",
                // If less ratios are given than tabs,
                // the remaining width is spread equally to the remaining tabs.
                // In this case 60, 20, 20
                "ratio": [60]
            }
        }
    ],
    "schemes": [...],
    "keybindings": [...]
}

That's only a quick and rough idea.

For the tabLayout and windowLayout I decided to define the shells only in the profile section, instead of in the tabLayout section. That way the shells always has the same place regardles of what you're configuring. It also allows for quick reordering shells while keeping the layout you defined.

@danielniccoli commented on GitHub (Nov 12, 2019): @gregchamblin Yeah, this would suffice in my opinion. Simply something like that: ![grafik](https://user-images.githubusercontent.com/2971735/68651998-df375e80-0528-11ea-87a0-fec1e0134bc3.png) > - What if someone wants to open the terminal with multiple tabs (what you've already discussed above) > - What about with multiple panes, in various different split configurations? How would we set that? > - Perhaps the user wants to auto-launch multiple windows? In different locations, etc. > - Would we want this multi-launch behavior to only happen on first launch, or every Terminal launch? I think that renaming the setting `defaultProfile` to `defaultProfiles` and have them accept a list of profiles should be the first thing to to. This should be a quick fix (said the amateur programmer 😛). For bullet points two and three, I think we should move a few terms around. What today is considered a *profile*, I would rename to *shell*. Then I would use *profiles* to combine multiple shells. In a profile you could either define all of those things mentioned in the bullet points, or tell Terminal to open the last session. The dropdown should be changed to display profiles, but also shells. Shells should be hidable from the list, in case they are only used in profiles. ![grafik](https://user-images.githubusercontent.com/2971735/68653574-53273600-052c-11ea-8180-84fa669cc7c9.png) > - With the nesting behavior you have above, what if someone had a recursive loop, where one profile A specified launching profile B, and B specified launching A? That would theoretically cause an infinite loop - do we allow that? With the quick concept I described above, this would not be possible as a shell is just the pure look and feel of exactly the described shell. You would not be able to nest a shell in a shell, that wouldn't make sense anymore. And profiles cannot be nested in themselves. A quick example ```jsonc { "$schema": "https://aka.ms/terminal-profiles-schema", "defaultProfile": "{11111111111}", "globals": { "initalCols": 180, "initialRows": 30 }, "shells": [ { "guid": "{...}", "hidden": false, "name": "cmd", "commandline": "cmd.exe" }, { "guid": "{...}", "hidden": false, "name": "Ubuntu" }, { "guid": "{...}", "hidden": true, // Only used in a profile. "name": "Ubuntu Dark Theme", "colorScheme": "Ubuntu Dark Theme" } ] "profiles": [ { "guid": "{11111111111}", "name": "My default profile", // If *layout and openLastSession are used in the same profile, throw error "openLastSession": true }, { // Opens one Terminal with multiple tabs "guid": "{...}", "name": "Side by side" "shells": [ "cmd", "Ubuntu" ] }, { // Opens one Terminal with multiple tabs. Layout: // ╔═══════╦═══╗ // ║ ║ ║ // ║ ╠═══╣ // ║ ║ ║ // ║ ║ ║ // ╚═══════╩═══╝ "guid": "{...}", "name": "Side by side" "shells": [ "cmd", "Ubuntu", "Ubuntu Dark Theme" ] // If *layout and openLastSession are used in the same profile, throw error // Instead of tabLayout, windowLayout can be used to open multiple windows instead of tabs "tabLayout": { // In the tabLayout (windowLayout) the defined shells would be used in order. // shell:cmd "split": "vertical", "ratio": [70, 30] { // shell:Ubuntu,Ubuntu Dark Theme "split": horizontal, "ratio": [40,70] } } }, { // Opens one Terminal with multiple tabs. Layout: // ╔═════╦══╦══╗ // ║ ║ ║ ║ // ╚═════╩══╩══╝ "guid": "{...}", "name": "Side by side" "shells": [ "cmd", "Ubuntu", "Ubuntu Dark Theme" ] // If *layout and openLastSession are used in the same profile, throw error "tabLayout": { // In the tabLayout (windowLayout) the defined shells would be used in order. // shell:cmd,Ubuntu,Ubuntu Dark Theme "split": "vertical", // If less ratios are given than tabs, // the remaining width is spread equally to the remaining tabs. // In this case 60, 20, 20 "ratio": [60] } } ], "schemes": [...], "keybindings": [...] } ``` That's only a quick and rough idea. - For the `tabLayout` and `windowLayout` I decided to define the `shells` only in the `profile` section, instead of in the `tabLayout` section. That way the `shells` always has the same place regardles of what you're configuring. It also allows for quick reordering shells while keeping the layout you defined.

claunia commented

@bormm commented on GitHub (Jan 9, 2020):

I want to extend the "shell" and multiple profiles discussion with my use case:
I want to open multiple powershell core windows with only one difference: they should have a different startup directory. I don't think that the current structure of profiles that contain all settings are appropriate for that, because that would produce a lot of duplicated settings. Maybe they is some need for profile or shell inheritance, so the "pwsh - directory A" and "pwsh - directory B" can inherit from the "pwsh - default" profile/shell.

Of course that would be an other complex issue, but I wanted to mention such use case for multiple startup "profiles".

@bormm commented on GitHub (Jan 9, 2020): I want to extend the "shell" and multiple profiles discussion with my use case: I want to open multiple powershell core windows with only one difference: they should have a different startup directory. I don't think that the current structure of profiles that contain all settings are appropriate for that, because that would produce a lot of duplicated settings. Maybe they is some need for profile or shell inheritance, so the "pwsh - directory A" and "pwsh - directory B" can inherit from the "pwsh - default" profile/shell. Of course that would be an other complex issue, but I wanted to mention such use case for multiple startup "profiles".

claunia commented

@zadjii-msft commented on GitHub (Jan 9, 2020):

@bormm I think we're planning on using some derivative of the commandline args functionality described in #3495/#4023 to help enable this functionality. With the wt commandline, you'll be able to do something like wt new-tab -p pwsh -d path/A/ ; new-tab -p pwsh -d /another/path and open two tabs in path/A/ and /another/path. Does that sound like what you're looking for?

@zadjii-msft commented on GitHub (Jan 9, 2020): @bormm I think we're planning on using some derivative of the commandline args functionality described in #3495/#4023 to help enable this functionality. With the wt commandline, you'll be able to do something like `wt new-tab -p pwsh -d path/A/ ; new-tab -p pwsh -d /another/path` and open two tabs in `path/A/` and `/another/path`. Does that sound like what you're looking for?

claunia commented

@bormm commented on GitHub (Jan 13, 2020):

@zadjii-msft No, because I want be able to open a tab with this directory at any time also in a existing WT instance. But I was mentioned to that ticket, what would be match my requirements: #3818

@bormm commented on GitHub (Jan 13, 2020): @zadjii-msft No, because I want be able to open a tab with this directory at any time also in a existing WT instance. But I was mentioned to that ticket, what would be match my requirements: #3818

claunia commented

@zadjii-msft commented on GitHub (Jan 13, 2020):

Ah okay, yea that's the issue you should follow. I've been working on #607 for a while now, so maybe I'm a little prone to thinking that it'll solve everything 😝

@zadjii-msft commented on GitHub (Jan 13, 2020): Ah okay, yea that's the issue you should follow. I've been working on #607 for a while now, so maybe I'm a little prone to [thinking that it'll solve everything ](https://en.wiktionary.org/wiki/if_all_you_have_is_a_hammer,_everything_looks_like_a_nail) 😝

claunia commented

@WSLUser commented on GitHub (Jan 13, 2020):

Having more than one way to support a feature or subset of a feature can't be a bad thing. That just gives people choices. In some cases, the use of wt.exe may be good enough and easier to do. In other cases #3818 may be the better option in which your current work might help speed up the process of resolving.

@WSLUser commented on GitHub (Jan 13, 2020): Having more than one way to support a feature or subset of a feature can't be a bad thing. That just gives people choices. In some cases, the use of wt.exe may be good enough and easier to do. In other cases #3818 may be the better option in which your current work might help speed up the process of resolving.

claunia commented

@ladal1 commented on GitHub (Feb 19, 2020):

I have to agree with @WSLUser that more solutions are better, since @DHowett-MSFT forwarded me to the command-line args in my issue I have started using them, but it does feels more like a good hack around the problem, rather then a full solution. You lose a some comforts that terminal has (live tile in start menu, starting with simply searching terminal and pressing enter etc...)

@ladal1 commented on GitHub (Feb 19, 2020): I have to agree with @WSLUser that more solutions are better, since @DHowett-MSFT forwarded me to the command-line args in my issue I have started using them, but it does feels more like a good hack around the problem, rather then a full solution. You lose a some comforts that terminal has (live tile in start menu, starting with simply searching terminal and pressing enter etc...)

claunia commented

@zadjii-msft commented on GitHub (Feb 19, 2020):

I think commandline args is more of a stop-gap for now - we're not intending on that being the singular long term solution to this problem. The idea I'm working with (at least in my own head) is to use the commandline args from #4023 to implement this functionality. Possibly as some combination of letting a profile use the arguments to launch multiple tabs/panes at once, and/or letting the user set a startupCommandline to override the defaultProfile on first launch

@zadjii-msft commented on GitHub (Feb 19, 2020): I think commandline args is more of a stop-gap for now - we're not intending on that being the singular long term solution to this problem. The idea I'm working with (at least in my own head) is to use the commandline args from #4023 to implement this functionality. Possibly as some combination of letting a profile use the arguments to launch multiple tabs/panes at once, and/or letting the user set a `startupCommandline` to override the `defaultProfile` on first launch

claunia commented

@zadjii-msft commented on GitHub (May 22, 2020):

Okay I've been noodling on this a bit.

I'm not totally sure that we should have "grouped profiles" - a profile that specifies a bunch of other profiles. That might lead to some unnecessary confusion, especially around the mixing of a "shell" profile and a "group" profile. There's a few scenarios we're looking at here:

I want to launch the Terminal with a bunch of tabs/panes all at once by default, not just from the commandline.
I want to press a keybinding and have it open a tab with a bunch of panes (or multiple tabs)
I want to click on an entry in the new tab button and have it open a tab with a bunch of panes (or multiple tabs)

So I think the first one could be satisfied with a defaultLaunchCommandline instead of a defaultProfile, and when that's present, uses that when there's no commandline provided at runtime.

The second will be satisfied by adding "a action that can run a bunch of actions" #5970. Then the user can just run a bunch of things when they press a keybinding.
The third will be satisfied by the "new tab menu customization" #5888 that will let users slam arbitrary actions into that menu. These menu actions could include the "run a bunch of actions" action that is used in the second.

Granted, all this is a showerthought, that needs to be linked to the right threads. Maybe we don't want defaultLaunchCommandline, but defaultActions, that uses a bunch of actions instead of a commandline?

@zadjii-msft commented on GitHub (May 22, 2020): Okay I've been noodling on this a bit. I'm not totally sure that we should have "grouped profiles" - a profile that specifies a bunch of other profiles. That might lead to some unnecessary confusion, especially around the mixing of a "shell" profile and a "group" profile. There's a few scenarios we're looking at here: * I want to launch the Terminal with a _bunch_ of tabs/panes all at once _by default_, not just from the commandline. * I want to press a keybinding and have it open a tab with a bunch of panes (or multiple tabs) * I want to click on an entry in the new tab button and have it open a tab with a bunch of panes (or multiple tabs) So I think the first one could be satisfied with a `defaultLaunchCommandline` instead of a `defaultProfile`, and when that's present, uses that when there's no commandline provided at runtime. The second will be satisfied by adding "a action that can run a bunch of actions" #5970. Then the user can just run a bunch of things when they press a keybinding. The third will be satisfied by the "new tab menu customization" #5888 that will let users slam arbitrary actions into that menu. These menu actions could include the "run a bunch of actions" action that is used in the second. Granted, all this is a showerthought, that needs to be linked to the right threads. Maybe we don't want `defaultLaunchCommandline`, but `defaultActions`, that uses a bunch of actions instead of a commandline?

claunia commented

@xmha97 commented on GitHub (Jun 18, 2020):

+1

@xmha97 commented on GitHub (Jun 18, 2020): +1

claunia commented

@7ranceaddic7 commented on GitHub (Aug 28, 2020):

Where is this? What is required to move it forward?

@7ranceaddic7 commented on GitHub (Aug 28, 2020): Where is this? What is required to move it forward?

claunia commented

@zadjii-msft commented on GitHub (Aug 28, 2020):

What is required to move it forward?

Nothing really. Someone needs to probably take my last comment in this thread and turn that into a formal spec (just to make sure the team's on board with the proposed implementation). Once that's approved, it's probably trivial to implement the defaultLaunchCommandline. The #1571 half of this might be harder to implement, but it's already got an approved spec, so that's not a big concern.

Really the main thing that this is blocked on is dev time. There's only so many engineers on the team and there's 1000+ issues on the backlog.

@zadjii-msft commented on GitHub (Aug 28, 2020): > What is required to move it forward? Nothing really. Someone needs to probably take my last comment in this thread and turn that into a formal spec (just to make sure the team's on board with the proposed implementation). Once that's approved, it's probably trivial to implement the `defaultLaunchCommandline`. The #1571 half of this might be harder to implement, but it's already got an approved spec, so that's not a big concern. Really the main thing that this is blocked on is dev time. There's only so many engineers on the team and there's 1000+ issues on the backlog.

claunia commented

@7ranceaddic7 commented on GitHub (Aug 28, 2020):

Someone needs to probably take my last comment in this thread and turn that into a formal spec

New to this, but I would really appreciate this feature. So, I'll mull it over and advance this.

(google: feature specifications, I did say I was new, but not afraid to jump in the deep-end. )

Thank you for the response.

@7ranceaddic7 commented on GitHub (Aug 28, 2020): > Someone needs to probably take my last comment in this thread and turn that into a formal spec New to this, but I would really appreciate this feature. So, I'll mull it over and advance this. (google: feature specifications, I did say I was new, but not afraid to jump in the deep-end. ) Thank you for the response.

claunia commented

@joe-mills commented on GitHub (Aug 28, 2020):

I'm now just using a shortcut for each project with the wt args I need to open all of the tabs in the right profile, layout, starting directories etc. It works well.

@joe-mills commented on GitHub (Aug 28, 2020): I'm now just using a shortcut for each project with the wt args I need to open all of the tabs in the right profile, layout, starting directories etc. It works well.

claunia commented

@alexbalez commented on GitHub (Sep 15, 2020):

I'm now just using a shortcut for each project with the wt args I need to open all of the tabs in the right profile, layout, starting directories etc. It works well.

I did this as well to replicate this functionality.

C:\Users[name]\AppData\Local\Microsoft\WindowsApps\wt.exe ; new-tab -p "Ubuntu"; focus-tab -t 0

That will start with two tabs: one with Powershell focused and Ubuntu in the background.

@alexbalez commented on GitHub (Sep 15, 2020): > I'm now just using a shortcut for each project with the wt args I need to open all of the tabs in the right profile, layout, starting directories etc. It works well. I did this as well to replicate this functionality. C:\Users\[name]\AppData\Local\Microsoft\WindowsApps\wt.exe ; new-tab -p "Ubuntu"; focus-tab -t 0 That will start with two tabs: one with Powershell focused and Ubuntu in the background.

claunia commented

@GordonSmith commented on GitHub (Jan 5, 2021):

What is required to move it forward?

Nothing really. Someone needs to probably take my last comment in this thread and turn that into a formal spec (just to make sure the team's on board with the proposed implementation). Once that's approved, it's probably trivial to implement the defaultLaunchCommandline. The #1571 half of this might be harder to implement, but it's already got an approved spec, so that's not a big concern.

Really the main thing that this is blocked on is dev time. There's only so many engineers on the team and there's 1000+ issues on the backlog.

Formal Spec: Enhance defaultProfile to support both a string (current) and a string array (opening 1 tab per item) proposed.

All the other comments are "over engineering" and should be moved to new issues?

@GordonSmith commented on GitHub (Jan 5, 2021): > > What is required to move it forward? > > Nothing really. Someone needs to probably take my last comment in this thread and turn that into a formal spec (just to make sure the team's on board with the proposed implementation). Once that's approved, it's probably trivial to implement the `defaultLaunchCommandline`. The #1571 half of this might be harder to implement, but it's already got an approved spec, so that's not a big concern. > > Really the main thing that this is blocked on is dev time. There's only so many engineers on the team and there's 1000+ issues on the backlog. **Formal Spec**: Enhance `defaultProfile` to support both a `string` (current) and a `string array` (opening 1 tab per item) proposed. All the other comments are "over engineering" and should be moved to new issues?

claunia commented

@zadjii-msft commented on GitHub (Jan 5, 2021):

What if I want to open with multiple panes, not just multiple tabs? How would I specify that then?

If defaultProfile was an array of profiles, then what happens when I click the new tab button? Which profile is opened?

I don't think these kinds of questions are "over engineering" 😄

@zadjii-msft commented on GitHub (Jan 5, 2021): What if I want to open with multiple panes, not just multiple tabs? How would I specify that then? If `defaultProfile` was an array of profiles, then what happens when I click the new tab button? Which profile is opened? I don't think these kinds of questions are "over engineering" 😄

claunia commented

@GordonSmith commented on GitHub (Jan 5, 2021):

@zadjii-msft multiple panes would be a different issue request surely.

Clicking the newTab button could open a new terminal matching the one to its left (but yes I do take your point :)).

But this is an issue opened May 2019 with what appears to be a straightforward request "Start with multiple tabs open" and its frustrating when it gets derailed with additional capabilities (panes).

...rant over...

@GordonSmith commented on GitHub (Jan 5, 2021): @zadjii-msft multiple panes would be a different issue request surely. Clicking the newTab button could open a new terminal matching the one to its left (but yes I do take your point :)). But this is an issue opened May 2019 with what appears to be a straightforward request "Start with multiple tabs open" and its frustrating when it gets derailed with additional capabilities (panes). ...rant over...

claunia commented

@zadjii-msft commented on GitHub (Jan 5, 2021):

But this is an issue opened May 2019 with what appears to be a straightforward request "Start with multiple tabs open" and its frustrating when it gets derailed with additional capabilities (panes).

Ah but see, part of my job is to make sure we design holistic solutions to problems. When there's such a obvious follow up feature, then it makes sense to think of not how to just solve the issue at hand, but also the follow up, in a single design. I don't want to have to build a solution for opening with multiple tabs, then build a solution for opening with multiple panes, then a solution for tabs, panes, and other actions, if it's clear from the onset where we want this feature to go.

We've only got so many engineers on the team, so there's only so much we can work on at a time. This is still in-scope for 2.0, so don't worry, be patient! This will come Soon^TM

@zadjii-msft commented on GitHub (Jan 5, 2021): > But this is an issue opened May 2019 with what appears to be a straightforward request "Start with multiple tabs open" and its frustrating when it gets derailed with additional capabilities (panes). Ah but see, part of my job is to make sure we design holistic solutions to problems. When there's such a obvious follow up feature, then it makes sense to think of not how to just solve the issue at hand, but also the follow up, in a single design. I don't want to have to build a solution for opening with multiple tabs, then build a solution for opening with multiple panes, then a solution for tabs, panes, and other actions, if it's clear from the onset where we want this feature to go. We've only got so many engineers on the team, so there's only so much we can work on at a time. This is still in-scope for 2.0, so don't worry, be patient! This will come Soon<sup>TM</sup>

claunia commented

@joe-mills commented on GitHub (Jan 5, 2021):

But this is an issue opened May 2019 with what appears to be a straightforward request "Start with multiple tabs open" and its frustrating when it gets derailed with additional capabilities (panes).

Tabs contain panes so surely its a necessary part of the original "Start with multiple tabs open". I think it gets confusing because currently profiles don't support multiple shells. The little plus button or launcher opens a profile as a tab or a pane which only makes sense when a profile is a single shell.

All of the wt arguments to configure how a tab and panes open are already available for what most want, it seems like its more of a UI challenge.

@joe-mills commented on GitHub (Jan 5, 2021): > But this is an issue opened May 2019 with what appears to be a straightforward request "Start with multiple tabs open" and its frustrating when it gets derailed with additional capabilities (panes). Tabs contain panes so surely its a necessary part of the original "Start with multiple tabs open". I think it gets confusing because currently profiles don't support multiple shells. The little plus button or launcher opens a profile as a tab or a pane which only makes sense when a profile is a single shell. All of the wt arguments to configure how a tab and panes open are already available for what most want, it seems like its more of a UI challenge.

claunia commented

@GordonSmith commented on GitHub (Jan 5, 2021):

@joe-mills if you can specify several panes for a single profile, then that will just work? If not then I would suggest making that a different issue.

Formal Spec II:

Add a new setting homeProfiles, an optional string array of profile guids which will open as individual tabs on terminal launch.
When omitted the current behaviour should be observed (open a single instance of defaultProfile).

@GordonSmith commented on GitHub (Jan 5, 2021): @joe-mills if you can specify several panes for a single profile, then that will just work? If not then I would suggest making that a different issue. **Formal Spec II**: * Add a new setting `homeProfiles`, an optional string array of profile guids which will open as individual tabs on terminal launch. * When omitted the current behaviour should be observed (open a single instance of `defaultProfile`).

claunia commented

@joe-mills commented on GitHub (Jan 5, 2021):

@GordonSmith I guess this might sound like a stupid question but what is a profile supposed to represent?

@joe-mills commented on GitHub (Jan 5, 2021): @GordonSmith I guess this might sound like a stupid question but what is a profile supposed to represent?

claunia commented

@zadjii-msft commented on GitHub (Jan 8, 2021):

Discussion that I had with @DHowett that I don't want to forget:

It's pretty much trivial to implement "startupActions": "new-tab ; split-pane -p PowerShell" today. This would be a "proceedural" style solution
We might want in the future to also do a "declarative" style solution, which would be more like "startupLayout": { "tabs": [ {"panes": { "profile": "PowerShell", "size": 0.50 }, { "profile": "Ubuntu", "size": 0.50 } } ] }. (typing that out did feel gross though)
We're going to need some sort of declarative layout for session restore and tearout anyways, but we don't have any of that code yet

@zadjii-msft commented on GitHub (Jan 8, 2021): Discussion that I had with @DHowett that I don't want to forget: * It's pretty much trivial to implement `"startupActions": "new-tab ; split-pane -p PowerShell"` today. This would be a "proceedural" style solution * We might want in the future to also do a "declarative" style solution, which would be more like `"startupLayout": { "tabs": [ {"panes": { "profile": "PowerShell", "size": 0.50 }, { "profile": "Ubuntu", "size": 0.50 } } ] }`. (typing that out did feel gross though) * We're going to need some sort of declarative layout for session restore and tearout anyways, but we don't have any of that code _yet_

claunia commented

@Don-Vito commented on GitHub (Jan 11, 2021):

Discussion that I had with @DHowett that I don't want to forget:

* It's pretty much trivial to implement `"startupActions": "new-tab ; split-pane -p PowerShell"` today. This would be a "proceedural" style solution

* We might want in the future to also do a "declarative" style solution, which would be more like `"startupLayout": { "tabs": [ {"panes": { "profile": "PowerShell", "size": 0.50 }, { "profile": "Ubuntu", "size": 0.50 } } ] }`. (typing that out did feel gross though)

* We're going to need some sort of declarative layout for session restore and tearout anyways, but we don't have any of that code _yet_

@zadjii-msft - what should be the behavior of startupActions (and of additional approaches) when we get command line arguments as well:

Should we use command line arguments only?
Should we concat the command line arguments with startupActions. If so
- In what order?
- If the second part doesn't start with the new-tab - should we still insert it or to continue applying the actions on the current tab?

@Don-Vito commented on GitHub (Jan 11, 2021): > > > Discussion that I had with @DHowett that I don't want to forget: > > * It's pretty much trivial to implement `"startupActions": "new-tab ; split-pane -p PowerShell"` today. This would be a "proceedural" style solution > > * We might want in the future to also do a "declarative" style solution, which would be more like `"startupLayout": { "tabs": [ {"panes": { "profile": "PowerShell", "size": 0.50 }, { "profile": "Ubuntu", "size": 0.50 } } ] }`. (typing that out did feel gross though) > > * We're going to need some sort of declarative layout for session restore and tearout anyways, but we don't have any of that code _yet_ @zadjii-msft - what should be the behavior of `startupActions` (and of additional approaches) when we get command line arguments as well: * Should we use command line arguments only? * Should we concat the command line arguments with `startupActions`. If so * In what order? * If the second part doesn't start with the new-tab - should we still insert it or to continue applying the actions on the current tab?

claunia commented

@zadjii-msft commented on GitHub (Jan 12, 2021):

I'd expect that not by providing commandline args, that would override the startupActions. So wt new-tab would still just open a single tab with the default profile, even if there's a longer startupActions set. That way you could still manually get a specific layout, even with startupActions set. I'm thinking maybe some tool out there wants to ship a helper script to open a WT window with some pre-configured tabs. By overriding the startupActions with the commandline that's passed in, we allow this scenario to still work as expected.

We had discussed limiting startupActions to the actions that are also commandline subcommands, because those are the ones that we know will work during startup.

I believe we also at one point discussed that startupActions should also use the implicit new-tab - if the first command isn't new-tab, we should insert one at the start.

@zadjii-msft commented on GitHub (Jan 12, 2021): I'd expect that not by providing commandline args, that would override the `startupActions`. So `wt new-tab` would still just open a single tab with the default profile, even if there's a longer `startupActions` set. That way you could still manually get a specific layout, even with `startupActions` set. I'm thinking maybe some tool out there wants to ship a helper script to open a WT window with some pre-configured tabs. By overriding the `startupActions` with the commandline that's passed in, we allow this scenario to still work as expected. We had discussed limiting `startupActions` to the actions that are also commandline subcommands, because those are the ones that we _know_ will work during startup. I believe we also at one point discussed that `startupActions` should also use the implicit `new-tab` - if the first command isn't `new-tab`, we should insert one at the start.

claunia commented

@Don-Vito commented on GitHub (Jan 12, 2021):

oint discussed that startupActions should also use the implicit new-tab - if the first command isn't new-tab, we should insert one at the start.

Makes sense! If I you are OK with it, I will try to add something like this.. Sounds straightforward (famous last words).

@Don-Vito commented on GitHub (Jan 12, 2021): > oint discussed that `startupActions` should also use the implicit `new-tab` - if the first command isn't `new-tab`, we should insert one at the start. Makes sense! If I you are OK with it, I will try to add something like this.. Sounds straightforward (famous last words).

claunia commented

@Makishima commented on GitHub (Jan 12, 2021):

Just want to show up my case:
I'm interested in to start wt with few tabs - wsl and PS but when hit 'New tab' I'm often want to open just new wsl only

@Makishima commented on GitHub (Jan 12, 2021): Just want to show up my case: I'm interested in to start wt with few tabs - wsl and PS but when hit 'New tab' I'm often want to open just new wsl only

claunia commented

@zadjii-msft commented on GitHub (Mar 26, 2021):

You know, startupActions is a perfectly good answer to this problem. I don't think this needs to be left open any longer.

@zadjii-msft commented on GitHub (Mar 26, 2021): You know, `startupActions` is a perfectly good answer to this problem. I don't think this needs to be left open any longer.

claunia commented