Terminal: Feature Request: Task Bar jumplist should show items from profile

[RobCannon]

The Task Bar context menu

should show the items from the configured profiles that populate the new shell menu

[HBelusca]

"DOS but not DOS" .... 🤔

[RobCannon]

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

[fcharlie]

@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

[zadjii-msft]

This is a _really good idea_

[Jarvis73]

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

[fcharlie]

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

[Jarvis73]

@fcharlie Perfect!

[mdtauk]

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

[topkecleon]

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.

[berwyn]

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

[miniksa]

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

[berwyn]

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.

[shanselman]

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

[zadjii-msft]

@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

[berwyn]

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

[zadjii-msft]

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.

[berwyn]

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?

[zadjii-msft]

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.

[miniksa]

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?

[berwyn]

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.

[miniksa]

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.

[berwyn]

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]

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.

[zadjii-msft]

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.

[berwyn]

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?

[miniksa]

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.

[DHowett-MSFT]

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")

[berwyn]

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]

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!

[miniksa]

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

[berwyn]

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

[miniksa]

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

[dsafa]

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]

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?

[zadjii-msft]

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

[berwyn]

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?

[ngetchell]

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

[kchoudhu]

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

[BaconTentacles]

Yes, please. With syntactic sugar on top.

[gamagan]

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

[ameltzerMSFT]

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.

[clarkezone]

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

[zadjii-msft]

Not yet. I believe it's next up on @leonMSFT's todo list - hence why it's in the 1.4 milestone.

[clarkezone]

If you need help happy to take a stab.

[msftbot[bot]]

:tada:This issue was addressed in #7515, which has now been successfully released as Windows Terminal Preview v1.4.2652.0.:tada:

Handy links:

• Release Notes
• Store Download