There’s still no satisfactory solution to this and I still think it’s not that much of a problem to fix as there are so many control mechanisms in the config but none that really fits.
A workaround is still: follow_mouse = 0 and float_switch_override_focus = 0
But man, this just feels awful, having no follow_mouse sucks.
To sum the current problem up:
In Rider, open CTRL+Shift+F to find in files
with default settings, the window erratically closes when moving the mouse
Same goes for CLion.
And please none of the, it’s XWayland excuses. Other compositors can handle it too and have the same follow_mouse/focus logic.
In the github post I’ve also added some proof of concept that this indeed just a faulty focusWindow logic.
I’ve also tried some windowrules posted but none where dealing with this problem.
I’m actually not sure if a forum post fits better for this or a github issue.
Just tested if I remember correctly or anything has changed. Wayland version actually has the same problem. ^^
Jetbrains is totally sleeping on Wayland, it still doesn’t even have drag&drop support. When looking at their issue tracker, it looks to me no work is done or progress has happened.
A better setting I’ve found right now is follow_mouse = 2 and float_switch_override_focus = 0
That at least keeps scrolling intact when mouse changes focus. Still not the best. I hope this can just get fixed or a proper workaround is found.
As far as I understand it, Riders “Find in files” window closes on click and follow_mouse=1 focus change simulates such a click so rider thinks it should close the window. What my code fix was doing is not refocus when the initialClass is the same. Vaxry wasn’t satisfied though for whatever reason. I thought the fix was very specific with also looking for floating windows but apparently not.
