Feature Request: Task Bar jumplist should show items from profile #840

@RobCannon commented on GitHub (May 8, 2019):

I just grabbed that screen shot from the blog post by @shanselman. His icons look better than mine!

@RobCannon commented on GitHub (May 8, 2019): I just grabbed that screen shot from the blog post by @shanselman. His icons look better than mine!

claunia commented

@fcharlie commented on GitHub (May 8, 2019):

@RobCannon The icon on the menu needs to be 32x32.
The icon for this console happens to be 32x32 bit 👇
https://github.com/microsoft/Terminal/blob/master/src/host/exe/console.ico

https://iconverticons.com/online/ Convert to 32x32 icon/png

This is the small icon I made: icons.zip

@fcharlie commented on GitHub (May 8, 2019): @RobCannon The icon on the menu needs to be 32x32. The icon for this console happens to be 32x32 bit 👇 [https://github.com/microsoft/Terminal/blob/master/src/host/exe/console.ico](https://github.com/microsoft/Terminal/blob/master/src/host/exe/console.ico) https://iconverticons.com/online/ Convert to 32x32 icon/png This is the small icon I made: [icons.zip](https://github.com/microsoft/Terminal/files/3157579/icons.zip) ![屏幕截图(1)](https://user-images.githubusercontent.com/6904176/57380917-7cad8080-71dc-11e9-8418-afc5005242fd.png)

claunia commented

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

This is a really good idea

@zadjii-msft commented on GitHub (May 8, 2019): This is a _really good idea_

claunia commented

2026-01-30 22:06:07 +00:00

@Jarvis73 commented on GitHub (May 9, 2019):

@fcharlie How can I add icons to the shell list just like that in your picture?

@Jarvis73 commented on GitHub (May 9, 2019): @fcharlie How can I add icons to the shell list just like that in your picture?

claunia commented

@fcharlie commented on GitHub (May 9, 2019):

@Jarvis73 Modify profile.json,
Look: A new Console for Windows - It's the open source Windows Terminal
https://gist.github.com/shanselman/221ef38d035fcf2836d664009f144eac

@fcharlie commented on GitHub (May 9, 2019): @Jarvis73 Modify profile.json, Look: [A new Console for Windows - It's the open source Windows Terminal](https://www.hanselman.com/blog/ANewConsoleForWindowsItsTheOpenSourceWindowsTerminal.aspx) [https://gist.github.com/shanselman/221ef38d035fcf2836d664009f144eac](https://gist.github.com/shanselman/221ef38d035fcf2836d664009f144eac)

claunia commented

2026-01-30 22:06:07 +00:00

@Jarvis73 commented on GitHub (May 9, 2019):

@fcharlie Perfect!

@Jarvis73 commented on GitHub (May 9, 2019): @fcharlie Perfect!

claunia commented

2026-01-30 22:06:07 +00:00

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

This context menu is called the Jumplist, for anyone planning to add this functionality in a PR

@mdtauk commented on GitHub (May 9, 2019): This context menu is called the Jumplist, for anyone planning to add this functionality in a PR

claunia commented

2026-01-30 22:06:08 +00:00

@topkecleon commented on GitHub (May 9, 2019):

The jump list should also feature an option to launch Terminal as an administrator.

There has been discussion in other issues (#146, #632) as to why individual tabs can't be administrative, but a lumplist option to launch the whole program as administrator, like PowerShell or cmd, would be great.

@topkecleon commented on GitHub (May 9, 2019): The jump list should also feature an option to launch Terminal as an administrator. There has been discussion in other issues (#146, #632) as to why individual tabs can't be administrative, but a lumplist option to launch the whole program as administrator, like PowerShell or cmd, would be great.

claunia commented

2026-01-30 22:06:08 +00:00

@berwyn commented on GitHub (May 10, 2019):

If you guys wouldn't mind, I'd love to take a stab at this!

@berwyn commented on GitHub (May 10, 2019): If you guys wouldn't mind, I'd love to take a stab at this!

claunia commented

2026-01-30 22:06:09 +00:00

@miniksa commented on GitHub (May 10, 2019):

@berwyn, presuming that the scope of what you're attempting to take on is:

Determine how to register a jump list inside the TerminalApp project
Only listing the items in the jump list that would already otherwise be accessible from the + dropdown menu

Then I am OK with you proceeding on this and I will assign you. If things start to get outside the proposal or off the rails, please consult with us here before going further.

Disclaimer: You're going to be among the first people we assign to do a feature that aren't on our direct team. It might be rough and neither we nor you know exactly what to expect. Bear with us. We're learning how to be open as much as you're learning how to work in our code. A few notes to take with you as you go:

Try to match the style of where you're working. Try Modern C++ practices. Try to use WIL/GSL referencing other example usages. Try to add TAEF tests when/if you can (we know the Terminal project is rough here right now).
Be ready for a back-and-forth on PR or for us to generate a bunch of "new rules" or "regulations" as an outcome of this experience.
We're as excited as you are to have this be open, but please only expect our promptish responses M-F 8am-5pm Pacific Daylight Time. Be patient otherwise, we're coming back to you. We just like our families and friends and sleep and we're honestly overwhelmed with the amount of traffic we have received in the last 3 days and are struggling to keep up.

Fair?

@miniksa commented on GitHub (May 10, 2019): @berwyn, presuming that the scope of what you're attempting to take on is: - Determine how to register a jump list inside the `TerminalApp` project - Only listing the items in the jump list that would already otherwise be accessible from the + dropdown menu Then I am OK with you proceeding on this and I will assign you. If things start to get outside the proposal or off the rails, please consult with us here before going further. Disclaimer: You're going to be among the first people we assign to do a feature that aren't on our direct team. It might be rough and neither we nor you know exactly what to expect. Bear with us. We're learning how to be open as much as you're learning how to work in our code. A few notes to take with you as you go: 1. Try to match the style of where you're working. Try Modern C++ practices. Try to use WIL/GSL referencing other example usages. Try to add TAEF tests when/if you can (we know the Terminal project is rough here right now). 2. Be ready for a back-and-forth on PR or for us to generate a bunch of "new rules" or "regulations" as an outcome of this experience. 3. We're as excited as you are to have this be open, but please only expect our promptish responses M-F 8am-5pm Pacific Daylight Time. Be patient otherwise, we're coming back to you. We just like our families and friends and sleep and we're honestly overwhelmed with the amount of traffic we have received in the last 3 days and are struggling to keep up. Fair?

claunia commented

2026-01-30 22:06:09 +00:00

@berwyn commented on GitHub (May 10, 2019):

I am 100% onboard with being a guinea pig for external contributions! And, indeed, I was planning to only introduce the profile items in the flyout to the jumplist.

@berwyn commented on GitHub (May 10, 2019): I am 100% onboard with being a guinea pig for external contributions! And, indeed, I was planning to only introduce the profile items in the flyout to the jumplist.

claunia commented

2026-01-30 22:06:09 +00:00

@shanselman commented on GitHub (May 10, 2019):

@HBelusca I called it that (in my own profile) because cmd.exe isn't DOS, but it is.

@shanselman commented on GitHub (May 10, 2019): @HBelusca I called it that (in my own profile) because cmd.exe isn't DOS, but it is.

claunia commented

2026-01-30 22:06:10 +00:00

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

@berwyn to add:

I'd probably do the jumplist in the WindowsTerminal project - we're trying to keep the UWP-like code in TerminalApp and the Win32-like code in WindowsTerminal. See src/cascadia/WindowsTerminal/AppHost.cpp for a place to start. You should be able to add methods to App to be able to query something like the profiles. Here be dragons though, the Profiles are not a C++/WinRT type, so they probably won't be exposable directly through the .idl. I can provide guidance here if you need help

@zadjii-msft commented on GitHub (May 10, 2019): @berwyn to add: I'd probably do the jumplist in the `WindowsTerminal` project - we're trying to keep the UWP-like code in `TerminalApp` and the Win32-like code in `WindowsTerminal`. See `src/cascadia/WindowsTerminal/AppHost.cpp` for a place to start. You should be able to add methods to `App` to be able to query something like the profiles. Here be dragons though, the Profiles are not a C++/WinRT type, so they probably won't be exposable directly through the `.idl`. I can provide guidance here if you need help

claunia commented

2026-01-30 22:06:10 +00:00

@berwyn commented on GitHub (May 10, 2019):

@zadjii-msft I may open a draft PR today for this, but I actually met with great success creating the jumplist and its entries, introducing a method IAsyncAction App::_CreateJumplist() that's invoked immediately following App::_CreateNewTabFlyout(). Where I'm struggling is on responding to the actual click events on the jumplist items.

On a straight UWP, it seems like the Windows::UI::Xaml::StartScreen helpers create links that are intended to be handled by the App::OnLaunched(LaunchedEventArgs const&). I dropped in an appropriate function on App before it occurred to me that the desktop bridge may or may not actually connect those events. As of right now, the breakpoints I've set there were never hit and I'm not sure if that's just my inexperience debugging C++ and/or WinRT, or if there's some linkage issue due to the desktop bridge.

I've also never touched UWP with C++, so it's a learning process in that regard, do I need to declare lifecycle functions in the idl? Because that could also be the problem here (and that only just ocurred to me as I'm tying this).

@berwyn commented on GitHub (May 10, 2019): @zadjii-msft I may open a draft PR today for this, but I actually met with great success creating the jumplist and its entries, introducing a method `IAsyncAction App::_CreateJumplist()` that's invoked immediately following `App::_CreateNewTabFlyout()`. Where I'm struggling is on responding to the actual click events on the jumplist items. On a straight UWP, it seems like the `Windows::UI::Xaml::StartScreen` helpers create links that are intended to be handled by the `App::OnLaunched(LaunchedEventArgs const&)`. I dropped in an appropriate function on `App` before it occurred to me that the desktop bridge may or may not actually connect those events. As of right now, the breakpoints I've set there were never hit and I'm not sure if that's just my inexperience debugging C++ and/or WinRT, or if there's some linkage issue due to the desktop bridge. I've also never touched UWP with C++, so it's a learning process in that regard, do I need to declare lifecycle functions in the idl? Because that could also be the problem here (and that only just ocurred to me as I'm tying this).

claunia commented

2026-01-30 22:06:10 +00:00

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

Oh yikes, that might be a harder problem that we thought then.

As you've discovered, we're not really a real UWP, we're a Win32 application. Our App.cpp/h/idl/xaml is not a real UWP "App" in this sense (it's actually just a trick to get XAML to work right for XAML Islands applications. I'm fairly certain (@DHowett-MSFT call me out if I'm wrong) even if you put Onlaunched in the idl, it wouldn't be called, because the application is getting activated as a traditional Win32 application.

So, how could we still make this work?

I don't really know how jumplists work, but if they let you specify commandline args, then maybe you could pass a --profile <guid> to wt.exe, and then parse the commandline in WindowsTerminal/main.cpp. Then, when creating the App, you'd pass the initial profile to the constructor. That's one option. Commandline args are something we want to add eventually, so you'd be the one to put some of the basics in place.

@miniksa any other ideas? I feel like there's gotta be an easier solution out there somewhere.

@zadjii-msft commented on GitHub (May 10, 2019): Oh yikes, that might be a harder problem that we thought then. As you've discovered, we're not really a real UWP, we're a Win32 application. Our App.cpp/h/idl/xaml is not a real UWP "App" in this sense (it's actually just a trick to get XAML to work right for XAML Islands applications. I'm _fairly_ certain (@DHowett-MSFT call me out if I'm wrong) even if you put Onlaunched in the idl, it wouldn't be called, because the application is getting activated as a traditional Win32 application. So, how could we still make this work? I don't really know how jumplists work, but if they let you specify commandline args, then maybe you could pass a `--profile <guid>` to `wt.exe`, and then parse the commandline in `WindowsTerminal/main.cpp`. Then, when creating the App, you'd pass the initial profile to the constructor. That's one option. Commandline args are something we want to add eventually, so you'd be the one to put some of the basics in place. @miniksa any other ideas? I feel like there's gotta be an easier solution out there somewhere.

claunia commented

@berwyn commented on GitHub (May 10, 2019):

I had that thought was well, and it's the direction I started sniffing in last night but didn't get much of a chance to dig into it. Barring any other ideas that crop up, is there a good reference I could look at for handling commandline args in a Microsoft-approved manner? Maybe something in ConHost that could (I assume ConsoleArguments) that could be brushed up and pulled into the shared bits?

@berwyn commented on GitHub (May 10, 2019): I had that thought was well, and it's the direction I started sniffing in last night but didn't get much of a chance to dig into it. Barring any other ideas that crop up, is there a good reference I could look at for handling commandline args in a Microsoft-approved manner? Maybe something in ConHost that could (I assume `ConsoleArguments`) that could be brushed up and pulled into the shared bits?

claunia commented

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

ConsoleArguments is where I'd start.

IIRC there was talk of adding getopt to the windows sdk (or CRT I don't remember) at some point, but idk if that ever actually happened or not.

@zadjii-msft commented on GitHub (May 10, 2019): `ConsoleArguments` is where I'd start. IIRC there was talk of adding `getopt` to the windows sdk (or CRT I don't remember) at some point, but idk if that ever actually happened or not.

claunia commented

@miniksa commented on GitHub (May 10, 2019):

For the arguments part, I agree. Go ahead and abstract/derive/baseclass/reuse ConsoleArguments into a shared component.

Probably into the Types one given its our grab bag of useful utilities shared across half-past everything.

Also, I'm doing some research into how jump lists work now to try to give you better advice. By what mechanism did you register the jump list? Is there some UWP/WinRT API to do it?

@miniksa commented on GitHub (May 10, 2019): For the arguments part, I agree. Go ahead and abstract/derive/baseclass/reuse `ConsoleArguments` into a shared component. Probably into the `Types` one given its our grab bag of useful utilities shared across half-past everything. Also, I'm doing some research into how jump lists work now to try to give you better advice. By what mechanism did you register the jump list? Is there some UWP/WinRT API to do it?

claunia commented

2026-01-30 22:06:12 +00:00

@berwyn commented on GitHub (May 10, 2019):

I leveraged the WinRT helpers to create the items, since that's on the list of APIs exposed to desktop bridge apps. I haven't had a chance to play with passing a full executable with args in for the arguments parameter, but it does seem to accept any arbitrary parameter.

I'll pop open a draft PR once I get home and have my hands on the code, should make it easier to discuss/iterate on the code.

@berwyn commented on GitHub (May 10, 2019): I leveraged the [WinRT helpers][winrt-jumplist] to create the items, since that's on the list of [APIs exposed to desktop bridge apps][desktop-bridge-list]. I haven't had a chance to play with passing a full executable with args in for the `arguments` parameter, but it does seem to accept any arbitrary parameter. I'll pop open a draft PR once I get home and have my hands on the code, should make it easier to discuss/iterate on the code. [winrt-jumplist]: https://docs.microsoft.com/en-us/uwp/api/windows.ui.startscreen.jumplist [desktop-bridge-list]: https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-supported-api

claunia commented

@miniksa commented on GitHub (May 10, 2019):

OK, reading that documentation, I think that figuring out how to catch the arguments coming in on the initial wmain and probably figuring out how to single-instance or communicate with the existing running process are going to be the challenges here.

I was hoping Jump List registration also included an eventing callback that would be fired in the same process it was registered from, but that seems to be not true. It just seems to be a registration that tells the shell to CreateProcess/ShellExecute something and maybe with arguments.

@miniksa commented on GitHub (May 10, 2019): OK, reading that documentation, I think that figuring out how to catch the arguments coming in on the initial wmain and probably figuring out how to single-instance or communicate with the existing running process are going to be the challenges here. I was hoping Jump List registration also included an eventing callback that would be fired in the same process it was registered from, but that seems to be not true. It just seems to be a registration that tells the shell to CreateProcess/ShellExecute something and maybe with arguments.

claunia commented

2026-01-30 22:06:12 +00:00

@berwyn commented on GitHub (May 11, 2019):

Alright, I've opened a draft (#689) to track progress on this. So far, it's just my first attempt at getting the items into the jumplist. I'll probably take some time this weekend to have a stab at parsing the commandline and launching tabs

@berwyn commented on GitHub (May 11, 2019): Alright, I've opened a draft (#689) to track progress on this. So far, it's just my first attempt at getting the items into the jumplist. I'll probably take some time this weekend to have a stab at parsing the commandline and launching tabs

claunia commented

2026-01-30 22:06:12 +00:00

@berwyn commented on GitHub (May 11, 2019):

As a follow-up to the IDL investigation, it turns out that declaring App::OnLaunched(LaunchActivatedEventArgs const&) in the IDL will actually cause that to be called at the appropriate point in the lifecycle of the app!

That said, it's still not helpful, with Explorer generating the same error message:

I also took a stab at passing both ms-appx:///WindowsTerminal.exe --profile <guid> and the result of Package::Current().InstalledLocation().GetFileAsync(L"WindowsTerminal.exe") with the same arguments, no dice there either.

I'll dig in and see how jumplists worked prior to UWP, this may be a case where the older Win32 API is more appropriate than the UWP-friendly one. Might also toy with OnActivated(IActivatedEventArgs const&) and see if there's any success there.

@berwyn commented on GitHub (May 11, 2019): As a follow-up to the IDL investigation, it turns out that declaring `App::OnLaunched(LaunchActivatedEventArgs const&)` in the IDL _will_ actually cause that to be called at the appropriate point in the lifecycle of the app! That said, it's still not helpful, with Explorer generating the same error message: ![image](https://user-images.githubusercontent.com/1403744/57563141-3e44cc80-7368-11e9-8e33-af99a75b7cd1.png) I also took a stab at passing both `ms-appx:///WindowsTerminal.exe --profile <guid>` and the result of `Package::Current().InstalledLocation().GetFileAsync(L"WindowsTerminal.exe")` with the same arguments, no dice there either. I'll dig in and see how jumplists worked prior to UWP, this may be a case where the older Win32 API is more appropriate than the UWP-friendly one. Might also toy with `OnActivated(IActivatedEventArgs const&)` and see if there's any success there.

claunia commented

2026-01-30 22:06:13 +00:00

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

I'm very excited to see that putting that method in the .idl makes it actually get called. Perhaps we're closer to being a real UWP than I thought :P

I'd maybe try just wt.exe --profile <guid>. We're registering wt.exe as an AppExecutionAlias, so ShellExecute/CreateProcess should be able to find us just from wt.exe.

@zadjii-msft commented on GitHub (May 12, 2019): I'm very excited to see that putting that method in the .idl makes it actually get called. Perhaps we're closer to being a real UWP than I thought :P I'd maybe try just `wt.exe --profile <guid>`. We're registering `wt.exe` as an AppExecutionAlias, so ShellExecute/CreateProcess should be able to find us just from `wt.exe`.

claunia commented

2026-01-30 22:06:13 +00:00

@berwyn commented on GitHub (May 13, 2019):

I did make an attempt to use just wt.exe ... and that didn't seem to help either. I get the feeling that JumpListItem::CreateWithArguments( ... ) is doing some extra work under the hood trying to match things up to the exe, but I'm having a hard time proving that out since the behaviour of CreateWithArguments isn't well documented past a singular C# example and there don't appear to be any real tools to inspect a jumplist item and figure out what it actually does.

I have to wonder if, on some level, it's a matter of window events not making it into the XAML Island. I read the docs on XAML Hosting and it does mention a IDesktopWindowXamlSourceNative2 with a PreTranslateMessage that forwards window events into the XAML Island and I wonder if that would help connect the XAML events, but looking at the toolkit I only found it in the Forms module and WPF module, but not in the Win32 module. Though I guess maybe it's unrelated since all the examples are about keyboard navigation?

@berwyn commented on GitHub (May 13, 2019): I did make an attempt to use just `wt.exe ...` and that didn't seem to help either. I get the feeling that `JumpListItem::CreateWithArguments( ... )` is doing some extra work under the hood trying to match things up to the exe, but I'm having a hard time proving that out since the behaviour of `CreateWithArguments` isn't well documented past a singular C# example and there don't appear to be any real tools to inspect a jumplist item and figure out what it actually _does_. I have to wonder if, on some level, it's a matter of window events not making it into the XAML Island. I read the [docs on XAML Hosting][docs] and it does mention a `IDesktopWindowXamlSourceNative2` with a `PreTranslateMessage` that forwards window events into the XAML Island and I wonder if that would help connect the XAML events, but looking at the toolkit I only found it in the [Forms module][forms] and [WPF module][wpf], but not in the Win32 module. Though I guess maybe it's unrelated since all the examples are about keyboard navigation? [docs]: https://docs.microsoft.com/en-us/windows/uwp/xaml-platform/using-the-xaml-hosting-api [forms]: https://github.com/windows-toolkit/Microsoft.Toolkit.Win32/blob/6cf474f55b9e01871c27fad87304ba6d52deaab2/Microsoft.Toolkit.Forms.UI.XamlHost/IDesktopWindowXamlSourceNative2.cs [wpf]: https://github.com/windows-toolkit/Microsoft.Toolkit.Win32/blob/6cf474f55b9e01871c27fad87304ba6d52deaab2/Microsoft.Toolkit.Wpf.UI.XamlHost/IDesktopWindowXamlSourceNative2.cs

claunia commented

2026-01-30 22:06:13 +00:00

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

Does it work with windowsterminal.exe since that's the real win32 app name and not the alias? Maybe it's just the alias code getting in the way?

We are trying to combine like 15 levels of shell and app execution extensions. The fewer we can bounce through will probably increase the chances of success.

@miniksa commented on GitHub (May 14, 2019): Does it work with `windowsterminal.exe` since that's the real win32 app name and not the alias? Maybe it's just the alias code getting in the way? We are trying to combine like 15 levels of shell and app execution extensions. The fewer we can bounce through will probably increase the chances of success.

claunia commented

@DHowett-MSFT commented on GitHub (May 14, 2019):

Probably not. That name isn't exposed to anybody -- anything that launches the package must either go through HAM or the app execution aliases (which are just magic reparse points that say "hey use the HAM stuff to launch this package")

@DHowett-MSFT commented on GitHub (May 14, 2019): Probably not. That name isn't exposed to anybody -- anything that launches the package must either go through HAM or the app execution aliases (which are just magic reparse points that say "hey use the HAM stuff to launch this package")

claunia commented

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

So, I had a thought today and dug through the packaging app. I wonder if this is a problem with using development mode where the app alias is registered as wtd.exe (see here). I'm going to play with that angle and see if that gets any more successful.

@berwyn commented on GitHub (May 14, 2019): So, I had a thought today and dug through the packaging app. I wonder if this is a problem with using development mode where the app alias is registered as `wtd.exe` ([see here][manifest]). I'm going to play with that angle and see if that gets any more successful. [manifest]: https://github.com/microsoft/Terminal/blob/master/src/cascadia/CascadiaPackage/Package-Dev.appxmanifest#L48-L54

claunia commented

@berwyn commented on GitHub (May 15, 2019):

Played around with it some more and I'm not sure that changing anything inside the string arguments here is helping. Went on a hunch and examined the AppX manifest and did notice in the schema that only uap5:Extension supports windows.appExecutionAlias and tried updating the manifest to reflect that. Still no dice. I'm actually somewhat stumped on this one!

@berwyn commented on GitHub (May 15, 2019): Played around with it some more and I'm not sure that changing anything inside the string arguments here is helping. Went on a hunch and examined the AppX manifest and did notice in [the schema][uap5-schema] that only `uap5:Extension` supports `windows.appExecutionAlias` and tried updating the manifest to reflect that. Still no dice. I'm actually somewhat stumped on this one! [uap5-schema]: https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-uap5-extension

claunia commented

@miniksa commented on GitHub (May 21, 2019):

@berwyn, if you can't figure it out, that's fine. You're welcome to take a stab at a different issue and just park this investigation for now. None of us know what to do here either, so it's your choice. Keep digging or find something else.

@miniksa commented on GitHub (May 21, 2019): @berwyn, if you can't figure it out, that's fine. You're welcome to take a stab at a different issue and just park this investigation for now. None of us know what to do here either, so it's your choice. Keep digging or find something else.

claunia commented

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

Yeah, I think that I'm going to shelf this for now. I took a stab at the old Win32 API over the weekend and didn't face much success there either, and all my googling turned up was a recommendation to use the UWP APIs instead for desktop apps because of some registry hoop nonsense the legacy API required.

I'll leave the draft PR open in case anyone else wants to take a stab using my code as a base (or in case I have a moment of brilliant inspiration in the near future).

@berwyn commented on GitHub (May 22, 2019): Yeah, I think that I'm going to shelf this for now. I took a stab at the old Win32 API over the weekend and didn't face much success there either, and all my googling turned up was a recommendation to use the UWP APIs instead for desktop apps because of some registry hoop nonsense the legacy API required. I'll leave the draft PR open in case anyone else wants to take a stab using my code as a base (or in case I have a moment of brilliant inspiration in the near future).

claunia commented

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

@berwyn, thanks for the attempt anyway. The investigation work and conclusion that "this is hard" is also valuable. Feel free to pick up a different issue if you like!

@miniksa commented on GitHub (May 22, 2019): @berwyn, thanks for the attempt anyway. The investigation work and conclusion that "this is hard" is also valuable. Feel free to pick up a different issue if you like!

claunia commented

@dsafa commented on GitHub (Jun 10, 2019):

I was curious and also did some investigation, following the same thread. The only new piece of information I could dig up was this message in the event viewer which occurs when the jump list item is clicked:
Activation for WindowsTerminalDev_8wekyb3d8bbwe!App failed. Error code: This app does not support the contract specified or is not installed.. Activation phase: No phase defined

There are very few references to that message and I couldn't find out anything else. Perhaps someone else can make sense of it.

@dsafa commented on GitHub (Jun 10, 2019): I was curious and also did some investigation, following the same thread. The only new piece of information I could dig up was this message in the event viewer which occurs when the jump list item is clicked: `Activation for WindowsTerminalDev_8wekyb3d8bbwe!App failed. Error code: This app does not support the contract specified or is not installed.. Activation phase: No phase defined` There are very few references to that message and I couldn't find out anything else. Perhaps someone else can make sense of it.

claunia commented

@dsafa commented on GitHub (Jun 17, 2019):

I got jumplists working using the COM api directly (ICustomDestinationList) instead of the winrt api. It calls wt/wtd.exe to open to application. This is just a minimal example to get it working and there are other details to consider like handling new and deleted profiles.
If this is the way we want to proceed with this feature, I can add full details. Perhaps a Spec?

@dsafa commented on GitHub (Jun 17, 2019): I got jumplists working using the COM api directly (ICustomDestinationList) instead of the winrt api. It calls `wt/wtd.exe` to open to application. This is just a minimal example to get it working and there are other details to consider like handling new and deleted profiles. If this is the way we want to proceed with this feature, I can add full details. Perhaps a Spec? ![jumplists](https://user-images.githubusercontent.com/7334282/59632396-fc453e00-90fe-11e9-838b-1c00f9c3fe7b.gif)

claunia commented

@zadjii-msft commented on GitHub (Jun 18, 2019):

@dsafa That's incredible! I'd definitely greenlight writing a spec to nail some of the details. Great work!

@zadjii-msft commented on GitHub (Jun 18, 2019): @dsafa That's incredible! I'd definitely greenlight writing a spec to nail some of the details. Great work!

claunia commented

@berwyn commented on GitHub (Jun 19, 2019):

Awesome stuff! Definitely feeling the lack of COM skills on my side now :V

I suppose, then, it's safe to close my draft in favour of @dsafa opening a PR?

@berwyn commented on GitHub (Jun 19, 2019): Awesome stuff! Definitely feeling the lack of COM skills on my side now :V I suppose, then, it's safe to close my draft in favour of @dsafa opening a PR?

claunia commented

@ngetchell commented on GitHub (Dec 31, 2019):

I feel like this is an important feature and would like to see it brought to the product soon!

@ngetchell commented on GitHub (Dec 31, 2019): I feel like this is an important feature and would like to see it brought to the product soon!

claunia commented

@kchoudhu commented on GitHub (Feb 4, 2020):

Just dropping by to say that this would be an excellent, excellent addition to the terminal program.

@kchoudhu commented on GitHub (Feb 4, 2020): Just dropping by to say that this would be an excellent, excellent addition to the terminal program.

claunia commented

@BaconTentacles commented on GitHub (Feb 12, 2020):

Yes, please. With syntactic sugar on top.

@BaconTentacles commented on GitHub (Feb 12, 2020): Yes, please. With syntactic sugar on top.

claunia commented

@gamagan commented on GitHub (Jul 31, 2020):

I haven't seen it mentioned specifically in this thread; please keep in mind this feature, of pinning script-files to jump list:
https://github.com/microsoft/terminal/issues/5261

@gamagan commented on GitHub (Jul 31, 2020): I haven't seen it mentioned specifically in this thread; please keep in mind this feature, of pinning script-files to jump list: https://github.com/microsoft/terminal/issues/5261

claunia commented

@ghost commented on GitHub (Aug 20, 2020):

I consider this a very necessary feature. Many times I don't want to launch the default when I launch terminal so it just wastes time to have to launch it to open a tab I don't need and then launch another tab.

ConEmu has jumplist functionality and I use it constantly.

@ghost commented on GitHub (Aug 20, 2020): I consider this a very necessary feature. Many times I don't want to launch the default when I launch terminal so it just wastes time to have to launch it to open a tab I don't need and then launch another tab. ConEmu has jumplist functionality and I use it constantly.

claunia commented

@clarkezone commented on GitHub (Aug 20, 2020):

Is any progress being made on this? If no maybe help is needed?

@clarkezone commented on GitHub (Aug 20, 2020): Is any progress being made on this? If no maybe help is needed?

claunia commented