Bug 460710

I don't think so; what problem are you encountering as a result of this change? The old search behavior is still there and only appears when the search text doesn't match any open windows.

New behavior:
If you want to open Thunar, you type "th<enter>". 
If Thunderbird is running at the same, you have to type "thuna<enter>" instead. 
If another instance of Thunar is running, it is impossible to open a new Thunar window through the overview.

Old behavior:
If you want to open Thunar, you type "th<enter>". 
If Thunderbird is running at the same, you type "th<enter>". 
If another instance of Thunar is running, but you need a new window, you type "th<enter>". 

Basically, the old version could be setup to act as a launcher and an overview at the same time (The same behavior as GNOME). Now you need two key combinations: one for the overview and one for the application launcher. It seems less powerful. 

Is there a different way to achieve the same?

Got it, I can see how the new UX has regressed that specific use case. Spacebar heating. :)

(In reply to Nate Graham from comment #3)
> Spacebar heating. :)

:D all right. Hey, if it makes the request sound less ridiculous: this is the default behavior, and pretty much the basis of UX in GNOME. I imagine that most users migrating from gnome would expect this behavior. GNOME users are the target audience for that effect, are they not?

We weren't explicitly trying to copy GNOME or attract GNOME users, no. If they like it and can switch to Plasma because of it, that's a bonus. :)

*** Bug 461343 has been marked as a duplicate of this bug. ***

I don't really care about copying gnome. I just want to be able to launch duplicate windows again on the same screen as well as launch windows without having to type the entire application name just to not match with an existing window. It would also be nice if we could not show the "no matching window" message on a virtual desktop that doesn't have any windows open. I can very clearly see that I haven't opened any windows yet.

One scenario that has hit me numerous times:

I was in Firefox, reading some article about some new features in Chrome. Then I triggered Overview to lauch Chrome, which of course failed because the title of Firefox had "Chrome" in it.

So it would be nice if there's a way to bring the search result even if window matches.
(And since usually there're few window matches, I guess there's enough room on screen for that.)

(In reply to Jin Liu from comment #8)
> One scenario that has hit me numerous times:
> 
> I was in Firefox, reading some article about some new features in Chrome.
> Then I triggered Overview to lauch Chrome, which of course failed because
> the title of Firefox had "Chrome" in it.
> 
> So it would be nice if there's a way to bring the search result even if
> window matches.
> (And since usually there're few window matches, I guess there's enough room
> on screen for that.)

Or when I'm seaching how to do something in an app and then try to open that app and it fails for the same reason you stated.

In both cases, when the app you want to launch is already running with an open window, you'll end up switching to it instead of opening a new instance of the app (if the app supports opening new instances when launched while open; many don't). What's the problem with this?

(In reply to Nate Graham from comment #10)
> In both cases, when the app you want to launch is already running with an
> open window, you'll end up switching to it instead of opening a new instance
> of the app (if the app supports opening new instances when launched while
> open; many don't). What's the problem with this?

Not quite. There are two cases here. 
1. The app is already running.
2. The app isn't already running.

In case 1 if the app is already running for example: say you have a picture open in gwenview. You can't then open another instance of gwenview to bring up a second picture and have them side by side.

In case 2. Lets say I have firefox open and then I search for bitwarden in firefox. If I then try to open bitwarden. It will match the firefox window instead. Therefore i can't launch bitwarden.

(In reply to Nate Graham from comment #10)
> In both cases, when the app you want to launch is already running with an
> open window, you'll end up switching to it instead of opening a new instance
> of the app (if the app supports opening new instances when launched while
> open; many don't). What's the problem with this?

Also you don't need to take that second example too literally. Like I'm not just typing bitwarden into a firefox tab and then trying to open bitwarden. Normally is more like "How to do xyz in some app".
Then I try to open that app and the firefox windows gets matched instead.
This isn't just firefox either. Let's say I took a screenshot of something online and named the screenshot something like "how to get to this feature in makemkv". If open that image in gwenview and then try to open makemkv. The gwenview window will be matched instead.

Ok, thanks.

These seem like quite niche edge cases, but nevertheless they seem valid to try to support better.

(In reply to Nate Graham from comment #13)
> Ok, thanks.
> 
> These seem like quite niche edge cases, but nevertheless they seem valid to
> try to support better.

Yeah, I think the problem here is: the same search box is present in 3 places: KRunner, Kickoff, Overview.
I never use the other two now, always using Overview to launch apps. Then the 1% time where it doesn't work is extra annoying.

(In reply to Nate Graham from comment #13)
> Ok, thanks.
> 
> These seem like quite niche edge cases, but nevertheless they seem valid to
> try to support better.

I hit this quite often, I wouldn't say it is a 1% situation. Overview is nowadays my solely launcher, it has taken ownership of my Meta+Space shortcut and it is great, but this really bugs me. The following situations are common for me:
- I have a Firefox tab open that matches and then I can't open the application I need (already mentioned)
- I have a terminal open in a given path and then I can't open that path quickly in dolphin as the terminal window gets matched

Showing filtered windows bellow search matches would work nice for me. As keyboard navigation pattern, pressing up/down arrows could select searches and right/left could select windows matches. Windows matches could be the default selection for a typing + Enter use case if we are concerned about quickly switching between windows..

Yeah, that might work.

Showing filtered windows and search results at the same time is too much stuff on the screen, especially for smaller screens and for people who want to read what's inside a window from the preview of the effect. Also, you can't reach every window with only the right/left arrow keys. 

What about a setting that lets you prioritize either filtering or searching? If you prioritize searching (which is what you would want to do in this case), then it would search when you start typing (like the old behavior) and start to filter only if there is no matching search result. And if the toggle prioritizes filtering (current behavior, would be the default setting), it would work like it currently does.

I think a setting would be fine!

> What about a setting that lets you prioritize 

A setting would be nice. It could be nicer if there was a way to unify the two, such that you could set your preference once in the global kde search settings, as in that you'd like to search through windows as well. The overview would just have an exception to display windows in a special with this option enabled. 

I think too many places with very similar options could be confusing (unless necessary).

Alright, I made a merge request that adds that priority setting and if enabled, only filters windows if there are no matches in the KRunner search. https://invent.kde.org/plasma/kwin/-/merge_requests/3406

(In reply to Niklas Stephanblome from comment #20)
> Alright, I made a merge request that adds that priority setting and if
> enabled, only filters windows if there are no matches in the KRunner search.
> https://invent.kde.org/plasma/kwin/-/merge_requests/3406

Thanks, looking forward to it

Someone else can look into this if anyone wants to do so. The merge request was not accepted, it was also pointed out that "the application search almost always matches, so when it's on, the window filtering function is basically disabled."

(In reply to Niklas Stephanblome from comment #22)
> Someone else can look into this if anyone wants to do so. The merge request
> was not accepted, it was also pointed out that "the application search
> almost always matches, so when it's on, the window filtering function is
> basically disabled."

Since disabling the window filtering function is the desired behavior, maybe a MR tailored for that (instead of prioritizing) would get accepted.

I'm in agreement with Nicolas Lindae. At this point I would rather just disable it. Krunner already returns open windows anyways, so I don't lose any functionality. Currently I am modifying the qml files to achieve this on my own machine, but it would be nice to not have to do that anymore.

Git commit b0d89791785c17c603cf350c28862570fe328ebf by Nate Graham, on behalf of Dashon Wells.
Committed on 18/10/2023 at 16:27.
Pushed by ngraham into branch 'master'.

plugins/overview: Make Window Filtering Optional

This commit makes window filtering optional by providing a checkbox
in Desktop Effects > Overview > Overview Configuration KCM. The
referenced bug report describes a bunch of the reasons why people
wanted this option.
FIXED-IN: 6.0

M  +15   -1    src/plugins/overview/kcm/overvieweffectkcm.ui
M  +3    -0    src/plugins/overview/overviewconfig.kcfg
M  +14   -0    src/plugins/overview/overvieweffect.cpp
M  +6    -0    src/plugins/overview/overvieweffect.h
M  +5    -4    src/plugins/overview/qml/main.qml

https://invent.kde.org/plasma/kwin/-/commit/b0d89791785c17c603cf350c28862570fe328ebf