Open descear opened 2 years ago
daniellandau
commented
2 years ago I have a feeling that the bigger problem you have is that the fuzzy matching just isn't very helpful. Could you try using the strict matching for a while and see if that works for your workflow?
descear
commented
2 years ago Strict matching does fix the example for launching an application, but not the example for switching windows. Nonetheless, I much prefer fuzzy matching. On this particular point, the main problem for me is that window list items get in the way when I try to launch an application, and application list items get in the way when I try to switch to a window. The screenshots were contrived examples to demonstrate the extent to which the extra list items can get in the way; it's most often not that extreme, but the extra list items do still cause issues.
Until recently, I was using the version in which the switcher and launcher were separate. This Issue is a request to re-separate them, and add an option to merge them, or a hotkey for the merged functionality, so that users can choose whether they want to be able to search only windows and only applications, or both at the same time.
For the way that I used them, the two modes provided distinct functionality; I could select the one that would behave in my desired way, and result in my desired outcome. With the features merged, it doesn't behave in a way that I desire, and achieving the correct outcome at best requires additional mental processing, and at worst is impossible.
Ideally, the two modes would mostly remain separate, and a preferences option would be added to toggle the behaviour of including applications in the switcher.
Here's some details to hopefully explain my use case:
Now that the two modes are merged:
I need to type my search query, find the target list item (ignoring the numerous unrelated list items), check whether the list item includes "→", and react accordingly. With there being so many unrelated list items, the index of the target item is practically unpredictable; I have to read the list items to determine which index to select.
If I'm looking for a window, and "→" is present in the list item, I press the number key corresponding to its index. If "→" is not present in the list item, there is no such window, so I press Esc.
If I'm looking for an application, and "→" is present in the list item, I select it using the arrow keys, and press Ctrl + Enter. If "→" is not present in the list item, I press the number key corresponding to its index.
In some cases, when I'm trying to launch an application, the list is so cluttered with window list items that the target application isn't even in the list (target application: "Date & Time (Settings)"):
I almost exclusively use it to launch applications, but the same applies when I'm trying to switch to a window (target window: "Settings - Chromium"):
When the switcher and launcher were separate:
After typing my search query, the target item was usually at the top, and if not, it was close below it; I didn't need to look over several unrelated list items. Also, for all of my common applications, I knew exactly what to type, and which position they would be in. So, most of the time, I would quickly launch an application without looking at the list at all.
If I was searching for a window, I knew that all list items were for windows, and if I was searching for an application, I knew that all list items were for applications; I didn't need to read the list item, check for "→", and then decide what to do.
Regardless of whether I was using the switcher or the launcher, using the number keys always had the desired effect; in the switcher, it would switch to a window, and in the launcher, it would launch an application.
If I was using the window switcher, I could instantly determine whether the window exists based on the presence of the list item; I didn't need to read the list item, and check for "→".
Related:
109
125
134
141
147