starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Terminal should support Taskbar.AppId so that different Terminal groups can glom separately on the taskbar #11328

New Issue
Open
opened 2026-01-31 02:44:39 +00:00 by claunia · 16 comments
claunia commented 2026-01-31 02:44:39 +00:00
Owner
Copy Link

Originally created by @dmachaj on GitHub (Nov 10, 2020).

Description of the new feature/enhancement

The current Terminal implementation always ends up with the same Taskbar.AppId so all Terminal instances on the system will "glom" (aka combine) into a single entry on the taskbar. My ideal workflow is to have separate taskbar entries for my separate Git clones and to use this separation (and distinct icons) to help me keep them straight. Within a given glom it would still be useful and good to support multiple tabs within Terminal.

In the past I have done this by having different shortcut files to cmd.exe and the /k flag allows them to have different enough identities to glom separately. Terminal doesn't seem to be compatible with this approach so they all still combine together. It would be nice if they could be separated back out.

If it is easier to implement it would still be valuable if this glomming was based on which Terminal profile was launched (e.g. cmd vs. powershell).

Proposed technical implementation details (optional)

The best documentation I could find on this old-style API is here: https://docs.microsoft.com/en-us/archive/msdn-magazine/2009/brownfield/windows-7-taskbar-apis. This concept has indeed existed since Win7 and as far as I know should continue to work essentially the same even on the latest versions of Win10.

Originally created by @dmachaj on GitHub (Nov 10, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> The current Terminal implementation always ends up with the same Taskbar.AppId so all Terminal instances on the system will "glom" (aka combine) into a single entry on the taskbar. My ideal workflow is to have separate taskbar entries for my separate Git clones and to use this separation (and distinct icons) to help me keep them straight. Within a given glom it would still be useful and good to support multiple tabs within Terminal. In the past I have done this by having different shortcut files to cmd.exe and the /k flag allows them to have different enough identities to glom separately. Terminal doesn't seem to be compatible with this approach so they all still combine together. It would be nice if they could be separated back out. If it is easier to implement it would still be valuable if this glomming was based on which Terminal profile was launched (e.g. cmd vs. powershell). # Proposed technical implementation details (optional) <!-- A clear and concise description of what you want to happen. --> The best documentation I could find on this old-style API is here: [https://docs.microsoft.com/en-us/archive/msdn-magazine/2009/brownfield/windows-7-taskbar-apis](https://docs.microsoft.com/en-us/archive/msdn-magazine/2009/brownfield/windows-7-taskbar-apis). This concept has indeed existed since Win7 and as far as I know should continue to work essentially the same even on the latest versions of Win10.
claunia added the Help WantedIssue-TaskProduct-TerminalArea-UserInterface labels 2026-01-31 02:44:40 +00:00
claunia commented 2026-01-31 02:44:40 +00:00
Author
Owner
Copy Link

@jantari commented on GitHub (Nov 11, 2020):

I'm curious as to how exactly you prevented the "gloming"using cmd.exe /k ?

Changing the window title with cmd.exe /k TITLE Group1 is not enough.

@jantari commented on GitHub (Nov 11, 2020): I'm curious as to how exactly you prevented the "gloming"using `cmd.exe /k` ? Changing the window title with `cmd.exe /k TITLE Group1` is not enough.
claunia commented 2026-01-31 02:44:41 +00:00
Author
Owner
Copy Link

@dmachaj commented on GitHub (Nov 11, 2020):

It's been a while since I set this up last so I forgot some details. I just set it back up to remind myself. Here are the instructions:

  1. On your desktop right click > New > Shortcut
  2. Enter "cmd.exe /k echo foo" as path > Next > enter "foo" as name
  3. Repeat steps with "bar" instead of "foo".
    You will now have two shortcut files on your desktop: foo and bar
  4. Right click "foo" > Pin to Taskbar
  5. Right click "bar" > Pin to Taskbar
    You will now have two cmd shortcuts pinned to the taskbar, foo and bar. They will launch and glom separately from each other.
@dmachaj commented on GitHub (Nov 11, 2020): It's been a while since I set this up last so I forgot some details. I just set it back up to remind myself. Here are the instructions: 1. On your desktop right click > New > Shortcut 2. Enter "cmd.exe /k echo foo" as path > Next > enter "foo" as name 3. Repeat steps with "bar" instead of "foo". You will now have two shortcut files on your desktop: foo and bar 4. Right click "foo" > Pin to Taskbar 5. Right click "bar" > Pin to Taskbar You will now have two cmd shortcuts pinned to the taskbar, foo and bar. They will launch and glom separately from each other.
claunia commented 2026-01-31 02:44:41 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 28, 2021):

Sorry to take so long to get to this. I see the value... should we just get the AppId from the launched LNK? I wonder if that even works with centennial app execution aliases.

@DHowett commented on GitHub (Jan 28, 2021): Sorry to take so long to get to this. I see the value... should we just get the AppId from the launched LNK? I wonder if that even works with centennial app execution aliases.
claunia commented 2026-01-31 02:44:41 +00:00
Author
Owner
Copy Link

@dmachaj commented on GitHub (Feb 2, 2021):

Something along those lines might work.

To step back a bit it might be simpler if the settings for Terminal simply allowed the AppID to be explicitly specified (or specified under the covers behind a checkbox to glom separately). The overall goal is that it would be nice if I could have my Terminal windows glom separately. The lnk file nonsense is just a hack to get it working with legacy cmd.exe. Directly being able to say which things should glom (or not) is really what I'm after. The AppID API may make this possible as long as Terminal is willing to call it in the expected circumstances.

@dmachaj commented on GitHub (Feb 2, 2021): Something along those lines might work. To step back a bit it might be simpler if the settings for Terminal simply allowed the AppID to be explicitly specified (or specified under the covers behind a checkbox to glom separately). The overall goal is that it would be nice if I could have my Terminal windows glom separately. The lnk file nonsense is just a hack to get it working with legacy cmd.exe. Directly being able to say which things should glom (or not) is really what I'm after. The AppID API may make this possible as long as Terminal is willing to call it in the expected circumstances.
claunia commented 2026-01-31 02:44:41 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 2, 2021):

So here's a thought - would it glom based on profile? Or something set (by the client shell) at runtime? If a window has two panes with different profiles open in the same tab, does switching the active pane switch which set of windows this window would glom to?

eg, we've got two taskbar groups: [profile A, profile B], and window 3 with panes [profile A|profile B] in it. Does switching between panes switch the group window 3 gloms to?

@zadjii-msft commented on GitHub (Feb 2, 2021): So here's a thought - would it glom based on profile? Or something set (by the client shell) at runtime? If a window has two panes with different profiles open in the same tab, does switching the active pane switch which set of windows this window would glom to? eg, we've got two taskbar groups: [profile A, profile B], and window 3 with panes [profile A|profile B] in it. Does switching between panes switch the group window 3 gloms to?
claunia commented 2026-01-31 02:44:41 +00:00
Author
Owner
Copy Link

@dmachaj commented on GitHub (Feb 11, 2021):

A major part of why I want this is so that I can pin the separate gloms onto my taskbar and keep them separate. I would expect it to glom based on what I launched.

  • If I had pinned profile A (e.g. cmd.exe) to the taskbar then clicking that should launch Terminal with cmd.exe active.
  • If I had pinned profile B (e.g. powershell.exe) to the taskbar then clicking that should launch Terminal with powershell.exe active.

In my opinion it would be acceptable, but not ideal, to then limit profile usage to whichever glom was used to launch Terminal. In this example if I launch the cmd.exe glom then perhaps I can only add cmd.exe tabs/panes to that instance. That wouldn't be ideal but it would work.

Better still would be if it could be used freely from that point and remains glommed to the taskbar button that started it all. That would allow different tabs to have different things active but all still be associated with a single workspace. (In my usage that would be per-clone of a massive project where it is common to have several clones). The taskbar gloms would make it easier to keep the different clones separate without me getting them confused with each other.

@dmachaj commented on GitHub (Feb 11, 2021): A major part of why I want this is so that I can pin the separate gloms onto my taskbar and keep them separate. I would expect it to glom based on what I launched. * If I had pinned profile A (e.g. cmd.exe) to the taskbar then clicking that should launch Terminal with cmd.exe active. * If I had pinned profile B (e.g. powershell.exe) to the taskbar then clicking that should launch Terminal with powershell.exe active. In my opinion it would be acceptable, but not ideal, to then limit profile usage to whichever glom was used to launch Terminal. In this example if I launch the cmd.exe glom then perhaps I can only add cmd.exe tabs/panes to that instance. That wouldn't be ideal but it would work. Better still would be if it could be used freely from that point and remains glommed to the taskbar button that started it all. That would allow different tabs to have different things active but all still be associated with a single workspace. (In my usage that would be per-clone of a massive project where it is common to have several clones). The taskbar gloms would make it easier to keep the different clones separate without me getting them confused with each other.
claunia commented 2026-01-31 02:44:42 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 28, 2023):

Note to self while writing over in #4768 - different defterm sessions should probably glom separately. Like, they each create a pseudo-profile or something, so that if the user did want to pin them, they'd somehow know what the real commandline they were launched with was (and could save the icon they were launched with)

@zadjii-msft commented on GitHub (Apr 28, 2023): Note to self while writing over in #4768 - different defterm sessions should probably glom separately. Like, they each create a pseudo-profile or something, so that if the user did want to pin them, they'd somehow know what the real commandline they were launched with was (and could save the icon they were launched with)
claunia commented 2026-01-31 02:44:42 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 16, 2023):

This might... not be possible. I just tried calling out to SetCurrentProcessExplicitAppUserModelID in a packaged scratch app, and it pretty immediately blew up the first time I tried to load a local file with StorageFile::GetFileFromPathAsync. Admittedly, that's a WinRT API that's not great and we'd typically try to avoid, but the point remains. I'm worried there are other parts of the framework that might explode unexpectedly by doing that. I'm not sure packaged apps are supposed to do be doing that.

@zadjii-msft commented on GitHub (Aug 16, 2023): This might... not be possible. I just tried calling out to `SetCurrentProcessExplicitAppUserModelID` in a packaged scratch app, and it pretty immediately blew up the first time I tried to load a local file with `StorageFile::GetFileFromPathAsync`. Admittedly, that's a WinRT API that's not great and we'd typically try to avoid, but the point remains. I'm worried there are other parts of the framework that might explode unexpectedly by doing that. I'm not sure packaged apps are supposed to do be doing that.
claunia commented 2026-01-31 02:44:42 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Aug 16, 2023):

What if you set the AppUserModelID just on a window and not on the whole process? https://learn.microsoft.com/en-us/windows/win32/shell/appids#where-to-assign-an-appusermodelid suggests SHGetPropertyStoreForWindow.

@KalleOlaviNiemitalo commented on GitHub (Aug 16, 2023): What if you set the AppUserModelID just on a window and not on the whole process? <https://learn.microsoft.com/en-us/windows/win32/shell/appids#where-to-assign-an-appusermodelid> suggests SHGetPropertyStoreForWindow.
claunia commented 2026-01-31 02:44:42 +00:00
Author
Owner
Copy Link

@kliffy542 commented on GitHub (Aug 16, 2023):

I know Edge is able to do this, and I'm pretty confident it is window
based. I've looked through this code a few months ago. Would it help to
know what Edge does?

Cliff

On Wed, Aug 16, 2023, 9:50 AM KalleOlaviNiemitalo @.***>
wrote:

What if you set the AppUserModelID just on a window and not on the whole
process?
https://learn.microsoft.com/en-us/windows/win32/shell/appids#where-to-assign-an-appusermodelid
suggests SHGetPropertyStoreForWindow.

—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/8216#issuecomment-1681185196
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJSRKEVON674KXTHWIHH3Z3XVUQAXBFKMF2HI4TJMJ2XIZLTS6BKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVE4DGNJUGA4DKMRUURXGC3LFVFUGC427NRQWEZLMQKSXMYLMOVS2UMJTGUZTQMZUHE2DBJDOMFWWLKLIMFZV63DBMJSWZAVFOZQWY5LFVIYTGNRUHEZTSMZYHGSG4YLNMWUWQYLTL5WGCYTFNSBKK5TBNR2WLKRRGM3DKMRVHEZDIONENZQW2ZNJNBQXGX3MMFRGK3FMON2WE2TFMN2F65DZOBS2YSLTON2WKQ3PNVWWK3TUUZ2G64DJMNZZNAVEOR4XAZNKOJSXA33TNF2G64TZUV3GC3DVMWUTCMBQGA3DAOJRGKBKI5DZOBS2K2LTON2WLJLWMFWHKZNJG42DAMJXHAYDCNECUR2HS4DFUVWGCYTFNSSXMYLMOVS2SOBTGU2DAOBVGI2IFJDUPFYGLJLMMFRGK3FFOZQWY5LFVIYTGNJTHAZTIOJUGCBKI5DZOBS2K3DBMJSWZJLWMFWHKZNKGEZTMNBZGM4TGOBZQKSHI6LQMWSWYYLCMVWKK5TBNR2WLKRRGM3DKMRVHEZDIONHORZGSZ3HMVZKMY3SMVQXIZI
.
You are receiving this email because you are subscribed to this thread.

Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
.

@kliffy542 commented on GitHub (Aug 16, 2023): I know Edge is able to do this, and I'm pretty confident it is window based. I've looked through this code a few months ago. Would it help to know what Edge does? Cliff On Wed, Aug 16, 2023, 9:50 AM KalleOlaviNiemitalo ***@***.***> wrote: > What if you set the AppUserModelID just on a window and not on the whole > process? > https://learn.microsoft.com/en-us/windows/win32/shell/appids#where-to-assign-an-appusermodelid > suggests SHGetPropertyStoreForWindow. > > — > Reply to this email directly, view it on GitHub > <https://github.com/microsoft/terminal/issues/8216#issuecomment-1681185196> > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AJSRKEVON674KXTHWIHH3Z3XVUQAXBFKMF2HI4TJMJ2XIZLTS6BKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVE4DGNJUGA4DKMRUURXGC3LFVFUGC427NRQWEZLMQKSXMYLMOVS2UMJTGUZTQMZUHE2DBJDOMFWWLKLIMFZV63DBMJSWZAVFOZQWY5LFVIYTGNRUHEZTSMZYHGSG4YLNMWUWQYLTL5WGCYTFNSBKK5TBNR2WLKRRGM3DKMRVHEZDIONENZQW2ZNJNBQXGX3MMFRGK3FMON2WE2TFMN2F65DZOBS2YSLTON2WKQ3PNVWWK3TUUZ2G64DJMNZZNAVEOR4XAZNKOJSXA33TNF2G64TZUV3GC3DVMWUTCMBQGA3DAOJRGKBKI5DZOBS2K2LTON2WLJLWMFWHKZNJG42DAMJXHAYDCNECUR2HS4DFUVWGCYTFNSSXMYLMOVS2SOBTGU2DAOBVGI2IFJDUPFYGLJLMMFRGK3FFOZQWY5LFVIYTGNJTHAZTIOJUGCBKI5DZOBS2K3DBMJSWZJLWMFWHKZNKGEZTMNBZGM4TGOBZQKSHI6LQMWSWYYLCMVWKK5TBNR2WLKRRGM3DKMRVHEZDIONHORZGSZ3HMVZKMY3SMVQXIZI> > . > You are receiving this email because you are subscribed to this thread. > > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> > . > >
claunia commented 2026-01-31 02:44:43 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 16, 2023):

AHG

Ignore me. I had a typo when I made that assertion.

             winrt::Windows::Storage::IStorageFile file{ nullptr };

@@ -353,7 +363,9 @@ namespace winrt::SampleApp::implementation

             else
             {
                 // Open the file, and load it into a SoftwareBitmap
-                auto file = co_await winrt::Windows::Storage::StorageFile::GetFileFromPathAsync(path);
+                file = co_await winrt::Windows::Storage::StorageFile::GetFileFromPathAsync(path);
             }

             // Get the software bitmap out of the file
@zadjii-msft commented on GitHub (Aug 16, 2023): AHG Ignore me. I had a typo when I made that assertion. ```diff winrt::Windows::Storage::IStorageFile file{ nullptr }; @@ -353,7 +363,9 @@ namespace winrt::SampleApp::implementation else { // Open the file, and load it into a SoftwareBitmap - auto file = co_await winrt::Windows::Storage::StorageFile::GetFileFromPathAsync(path); + file = co_await winrt::Windows::Storage::StorageFile::GetFileFromPathAsync(path); } // Get the software bitmap out of the file ```
claunia commented 2026-01-31 02:44:43 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 16, 2023):

Rolling back a step here -

The initial ask here in this thread is to group.... taskbar icons... by... profile? I'm not sure that is a UX that makes sense. Like, each taskbar entry is one window, right? (or, in the case of like, a tabbed application, there's some precedent for one per tab).

What then if there's a Terminal tab with a powershell next to a cmd.exe?

We'd need:

  • A public API for creating taskbar entries for tabs (and we'd use this per-pane)
    • it would have to work without an HWND
    • it would have to work even in a packaged context
  • We'd need to find a way to group those entries based on the profile used to start the pane

Other notes after ad2f6a764

okay, we make a TOOLWINDOW for each pane. We haven't had enough pain in our lives, let's add some more. If we set a glomming setting, then we give each of those hwnds a separate AUMID, depending on the setting.

taskbarGlomming AUMID Relaunch Command
none n/a wt.exe1
window window ID wt
tab windowID + tab id wt
pane windowID + tab id + pane ID wt -p {guid}
profile profile.guid wt -p {guid}

Clicking or activating the taskbar for that TOOLWINDOW would then activate the terminal... somehow.

Wait, no, that won't work.

  • TOOLWINDOWs don't show up in the taskbar
  • even if it did, how would we ever associate the taskbar preview of that tab/pane with the right source? Rendering a pane to a bitmap to stick in there sounds awful
  • Even if we did, then what happens to the actual root HWND of the Terminal itself? to what group does that now belong?

Like taskbarGlomming: window does make sense, and is something that we could do. But per-pane? Per-profile?

alternatively:

taskbarGlomming: profile - each window gloms based off the active pane's profile. If you change the active pane, this may change to glom to another group. We could then still make the relaunch command the -p {guid} version.

Every time it changes, it sounds like we'd have to re-build the jumplist.

  1. obv, these are the real path to wt, not just the alias ↩︎

@zadjii-msft commented on GitHub (Aug 16, 2023): Rolling back a step here - The initial ask here in this thread is to group.... taskbar icons... by... profile? I'm not sure _that_ is a UX that makes sense. Like, each taskbar entry is one window, right? (or, in the case of like, a tabbed application, there's some precedent for one per tab). What then if there's a Terminal tab with a powershell next to a cmd.exe? We'd need: * A public API for creating taskbar entries for tabs (and we'd use this per-pane) * it would have to work without an HWND * it would have to work even in a packaged context * We'd need to find a way to group those entries based on the profile used to start the pane ---- Other notes after ad2f6a764 ~okay, we make a TOOLWINDOW for each pane. We haven't had enough pain in our lives, let's add some more. If we set a `glomming` setting, then we give each of those hwnds a separate AUMID, depending on the setting.~ | `taskbarGlomming`| AUMID | Relaunch Command | |-----------|-------------|------| | `none` | n/a | `wt.exe`[^1] | | `window` | window ID | `wt` | | `tab` | windowID + tab id | `wt` | | `pane` | windowID + tab id + pane ID | `wt -p {guid}` | | `profile` | profile.guid | `wt -p {guid}` | Clicking or activating the taskbar for that TOOLWINDOW would then activate the terminal... somehow. Wait, no, that won't work. * TOOLWINDOWs don't show up in the taskbar * even if it did, how would we ever associate the taskbar preview of that tab/pane with the right source? Rendering a pane to a bitmap to stick in there sounds awful * Even if we did, then what happens to the actual root HWND of the Terminal itself? to what group does that now belong? Like `taskbarGlomming: window` does make sense, and is something that we could do. But per-pane? Per-profile? ---- alternatively: `taskbarGlomming: profile` - each window gloms based off the active pane's profile. If you change the active pane, this may change to glom to another group. We could then still make the relaunch command the `-p {guid}` version. Every time it changes, it sounds like we'd have to re-build the jumplist. [^1]: obv, these are the _real_ path to `wt`, not just the alias
claunia commented 2026-01-31 02:44:43 +00:00
Author
Owner
Copy Link

@daalbert commented on GitHub (Nov 16, 2023):

Having closely followed the ongoing discussions about taskbar icons and glom behavior, and inspired by some of my own hacking, I'd like to propose a concept: "groups."

  • Unique Identification: Each group would have a unique PKEY_AppUserModel_ID, specifically tied to the CASCADIA_HOSTING_WINDOW_CLASS window.
  • Streamlined User Experience: Introduce the concept of a default profile for each group to simplify user interaction and the implementation of taskbar behaviors.
  • Customization Options: Enable customizable icons or overlays for different groups.
  • Adaptable Settings: Incorporate other group-specific settings that could enhance functionality.

I believe this approach could offer a structured and versatile framework for managing taskbar interactions, especially in scenarios where the current abstractions fall short.

@daalbert commented on GitHub (Nov 16, 2023): Having closely followed the ongoing discussions about taskbar icons and glom behavior, and inspired by some of my own hacking, I'd like to propose a concept: "groups." - **Unique Identification**: Each group would have a unique `PKEY_AppUserModel_ID`, specifically tied to the `CASCADIA_HOSTING_WINDOW_CLASS` window. - **Streamlined User Experience**: Introduce the concept of a default profile for each group to simplify user interaction and the implementation of taskbar behaviors. - **Customization Options**: Enable customizable icons or overlays for different groups. - **Adaptable Settings**: Incorporate other group-specific settings that could enhance functionality. I believe this approach could offer a structured and versatile framework for managing taskbar interactions, especially in scenarios where the current abstractions fall short.
claunia commented 2026-01-31 02:44:44 +00:00
Author
Owner
Copy Link

@damnskippy commented on GitHub (Oct 12, 2024):

Has anyone found any clever work around for this issue? Would love to keep different terminal windows under different groups.

@damnskippy commented on GitHub (Oct 12, 2024): Has anyone found any clever work around for this issue? Would love to keep different terminal windows under different groups.
claunia commented 2026-01-31 02:44:44 +00:00
Author
Owner
Copy Link

@chesucr commented on GitHub (Apr 21, 2025):

I found a workaround @damnskippy by downloading another instance of Windows Terminal from the release assets. I tried with Microsoft.WindowsTerminal_1.22.10731.0_x64.zip

After extracting the contents, you can duplicate the folder as many times as you like. Each copy functions as a separate installation, so you can configure each one to launch a different profile. This way, you can have multiple terminals open simultaneously, each with its own separate window. You can even create a shortcut with the icon and profile you wish to open. Make sure to write, in the shortcut target, the name of your profile:

wt.exe --profile "Debian"

I haven’t done deep testing yet, so there may be issues at some point. I am working with Windows 11. The profiles are shared among all the "installations"

Image

@chesucr commented on GitHub (Apr 21, 2025): I found a workaround @damnskippy by downloading another instance of Windows Terminal from the [release assets](https://github.com/microsoft/terminal/releases/tag/v1.22.10731.0). I tried with `Microsoft.WindowsTerminal_1.22.10731.0_x64.zip` After extracting the contents, you can duplicate the folder as many times as you like. Each copy functions as a separate installation, so you can configure each one to launch a different profile. This way, you can have multiple terminals open simultaneously, each with its own separate window. You can even create a shortcut with the icon and profile you wish to open. Make sure to write, in the shortcut target, the name of your profile: wt.exe --profile "Debian" I haven’t done deep testing yet, so there may be issues at some point. I am working with Windows 11. The profiles are shared among all the "installations" ![Image](https://github.com/user-attachments/assets/5fa6d672-dad7-4afa-a480-aad14fe3f522)
claunia commented 2026-01-31 02:44:44 +00:00
Author
Owner
Copy Link

@SpicyLeone commented on GitHub (Oct 3, 2025):

@zadjii-msft
May I suggest a solution that would IMO solve some other UX "problems" as well.

Profile Locking
Locks the subsequent tabs to use the same profile

I think the best way of implementing would be a per-profile setting (slider) which would force a terminal application opened with that specific profile to only open new tabs with that profile. You could then treat that instance of Terminal as a separate window and also display it separately in the taskbar. Also you could assign it the same icon as the Terminal profile that is being used, which would further improve the distinction.

Another thing that would enable you to do is to use --size and -p arguments "together" to make the whole window size based on the font (also scrollbar visibility and padding) settings of the selected profile. This would solve the need of some (old school) terminal-based programs to use e.g. 80 columns x 25 rows fixed size window to function properly, which currently forces you to use the same starting size for all Terminal instances or just give up and run them in conhost.

@SpicyLeone commented on GitHub (Oct 3, 2025): @zadjii-msft May I suggest a solution that would IMO solve some other UX "problems" as well. **Profile Locking** _Locks the subsequent tabs to use the same profile_ I think the best way of implementing would be a per-profile setting (slider) which would force a terminal application opened with that specific profile to only open new tabs with that profile. You could then treat that instance of Terminal as a separate window and also display it separately in the taskbar. Also you could assign it the same icon as the Terminal profile that is being used, which would further improve the distinction. Another thing that would enable you to do is to use `--size` and `-p` arguments "together" to make the whole window size based on the font (also scrollbar visibility and padding) settings of the selected profile. This would solve the need of some (old school) terminal-based programs to use e.g. 80 columns x 25 rows fixed size window to function properly, which currently forces you to use the same starting size for all Terminal instances or just give up and run them in conhost.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-UserInterface Help Wanted Issue-Task Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11328
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?