-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Terminal should support Taskbar.AppId so that different Terminal groups can glom separately on the taskbar #8216
Comments
I'm curious as to how exactly you prevented the "gloming"using Changing the window title with |
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:
|
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. |
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. |
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? |
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.
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. |
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) |
This comment was marked as resolved.
This comment was marked as resolved.
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. |
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 |
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:
Other notes after ad2f6a7
Clicking or activating the taskbar for that TOOLWINDOW would then activate the terminal... somehow. Wait, no, that won't work.
Like alternatively:
Every time it changes, it sounds like we'd have to re-build the jumplist. Footnotes
|
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."
I believe this approach could offer a structured and versatile framework for managing taskbar interactions, especially in scenarios where the current abstractions fall short. |
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.
The text was updated successfully, but these errors were encountered: