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

[dmachaj]

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.

[jantari]

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.

[dmachaj]

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.

[DHowett]

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.

[dmachaj]

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.

[zadjii-msft]

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?

[dmachaj]

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.

[zadjii-msft]

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]

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.

[KalleOlaviNiemitalo]

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.

[kliffy542]

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 .

[zadjii-msft]

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]

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

[daalbert]

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.

[damnskippy]

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

[chesucr]

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"

[SpicyLeone]

@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.