Powertoys: Migrate window walker into launcher

[crutkas]

We should only have one system, let’s migrate WW into a plug-in for launcher

[crutkas]

marking for v1, would be nice for build release.

[jstaro]

If so, I really hope you will be able to configure it to only use it as a switcher (or set a default), without having to use an additional special keyword, like all the launchers out there (which I cannot use for that reason). For me, pressing Win and start typing is my launcher.

[betsegaw]

Currently working on this. The basics are almost up and running and I should be able to start the PR this weekend.

[crutkas]

🔥🔥🔥🔥

[betsegaw]

@crutkas Here is the basics working... with a bug or two in the display but generally working. I had this during the day.

What has taken up more time is getting the Aero peek to work. Since the app is composed of multiple windows, our launcher window also gets hidden. Haven't been able to figure out a way around it.

Also, the key up+down selection doesn't work in launcher (though there is code that looks like it works, it doesn't) and I put in a fix for it but since I couldn't get the Aero peek to work, the fixes are sitting in the working branch (betsegaw/reenable-aero-ww).. feel free to cherry-pick the fixes if you ww isn't the only one that needs to know who is highlighted. Also along the fix is an addition to the public API that allows plugins to know when their result is highlighted.

Will give the Aero capability a shot next week. For now, I will clean up the code for just getting the basics working and start a PR.

[crutkas]

@alekhyareddy28 any ideas?

[alekhyareddy28]

@crutkas, I have a few thoughts regarding this -

• As you had previously mentioned, it would be cleaner to display the name of the plugin instead of the path under the title of the result.
• That being said, window walker and the program plugin both search for applications, while one searches for open applications, the other searches for all possible applications. So, for the results obtained by using the Program plugin, we could mention something like Type: Application and for the results obtained using the WindowWalker Plugin, we could display Type: Open Application.
• However, for that we need to ensure that the fuzzy matching techniques employed for both the plugins are the same so that the user gets a chance to open a new app and also switch to an open app while searching using the same keyword.
• Also, we need to rank the results in the same way for both the plugins to see applications first (either to open a new one or switch to an open one) then followed by files/folders. This would ensure that the results of program plugin and the window walker plugin are each separately sorted in the same way. We would have to give one plugin preference over the other though, so it would either be opening an application (Program plugin) followed by an already open application (WW plugin) or vice versa. So it would be as the following table or with the last two rows swapped,

| PowerLauncher |
|---------|
| Edge (program plugin) |
| Edge (Switch to Open Tab) |

We could also give the user a choice in the settings to give preference to new apps or to switch to open apps depending on what the choose more often.
@betsegaw, feel free to correct me and share your thoughts.

[betsegaw]

Good points @alekhyareddy28 .

I do think showing people the name of the application process in the case of Window Walker is an important scenario since a lot of times people come with the question "I have a terminal window, not sure which one", in which case they search for terminal.exe and then they can scroll through the list of options.

As for how the two scenarios live together (launching vs. switching) totally agree that we have to reconcile the two somehow and I would bet that people switch more often than they launch, in which case open window results should show up higher than general launch results. However, this introduces the possibility that it can make the launch experience significantly worse if window walker is returning a ton of results (maybe we limit the number of results from Window walker to maybe 2?).

I know @crutkas was opposed to it when someone brought signal words up but this might force us to reconsider. Especially considering that this is a Power user audience, signal words (or maybe even letters, such as a prefix l for launch or s for switch) might well worth be the price for speed. We can also continue to create a compromised scenario with some automatic ranking built in but with signal words, filter more directly.

[somil55]

@betsegaw I wasn't able to repro up+down arrow issue. Can you provide some more context on this ?

[betsegaw]

@somil55 - Put a log breakpoint on the code that handles the keyboard down preview (regular breakpoint would dismiss the launcher window by taking away focus).

https://github.com/microsoft/PowerToys/blob/0fb42c6129641052d6ed3bf6c5bd7973669b10bb/src/modules/launcher/PowerLauncher/MainWindow.xaml.cs#L222

The expected behavior is that every up/down key would trigger the log, but what actually happens is that you only get the first one and then subsequent ones are sent to the view in PowerLauncher.UI. The fix I put in place in my branch is to have the code mirrored in the PowerLauncher.UI as well (with some .NET reflection since I couldn't add a reference to the project with the view model).

https://github.com/microsoft/PowerToys/blob/0894dc97c3a5fad9ce898dfe8532b18b110a764c/src/modules/launcher/PowerLauncher.UI/LauncherControl.xaml.cs#L12

[somil55]

@betsegaw The selected element is currently not tracked because we can directly use the QuerySubmitted callback from autosuggest box for executing apps on enter/mouse click.

[betsegaw]

@crutkas, @alekhyareddy28 and @somil55 - For WW Aero view, I believe I am blocked. passing the top level window handle does not work with the windows Aero api.

As a reminder, the aero view was the functionality where as your scroll through the search results for open windows, when you have a window highlighted, all other windows go transparent so you can see the window you currently have selected.

The issue seems to be that the API (which is sort of an old windows API) takes in 2 windows to keep visible, and window walker passes the handle to it self (in this case Power Launcher) and the currently highlighted window. The highlighted window works but launcher disappears. Tried it a variety of methods, but it doesn't seem to work.

Can someone else give this a shot? The branch is betsegaw/reenable-aero-ww

[betsegaw]

@crutkas - Shall I remove the window walker standalone app?

[crutkas]

@betsegaw, think we did already

[betsegaw]

Awesome! Didn't see it...