For each binding of the mouse button, the user can choose (when setting it up) whether or not to focus whichever window (or in-window object if it matters) is under the mouse cursor. That way, for instance, if I set up a mouse button to F5 and move the cursor to a web-browser window to refresh it, it will refresh the browser window under the pointer instead of starting an application under the debugger in the Qt Creator window on the other screen that was last under focus. This setting will only matter if 'Shift Focus on Hover' is OFF. The ability to do this, will make the setting in System Settings, superior to mouse-inbuilt remapping capabilities.
It's a bit hard for me to understand what the issue is; can you write specific steps to reproduce that indicate what issue you're having? See https://community.kde.org/Get_Involved/Issue_Reporting#Steps_to_Reproduce Thanks!
STEPS TO REPRODUCE 0. System Settings -> Window Behaviour -> Focus -> Window Activation Policy = Click to Focus; Raise on Hover = disabled 0. System Settings -> Mouse -> Extra Mouse Buttons : Add a binding (Say, MouseExtraButton3) that does something relevant (Call it Event-A) to the Active Window - e.g. `F5` to refresh window in case of a web browser 1. Have 2 Windows (of any application or multiple applications that work with Event-A) open, side-by-side (say, window1 and window2) 2. Activate window1. 3. Move mouse pointer to window2 4. Click the MouseExtraButton3. OBSERVATION - Event-A occurs in window1 EXPECTATION - window2 gets activated with the "Click to Focus" rule - Event-A occurs in window2
It is to be noted that this might not be desirable for every binding and is better to be selected by the user on a per-binding basis.
There is definitely an inconsistency here. When it's a built-in extra mouse button function like "Back" or "Forward", it behaves like requested here (minus the configurability) - if you click the "Back" mouse button on a browser window that does not have focus, that background window that you clicked receives the mouse press event, and goes back one page in the history. The window that has focus at that point is not affected. It doesn't seem consistent to do this for built-in extra mouse buttons, but not for custom-bound ones.
> It doesn't seem consistent to do this for built-in extra mouse buttons, but not for custom-bound ones. Yes. Since the custom bindings make it act like a keyboard key, it gets rid of all mouse button press events. ___ One can also check that out by: 1. adding a debug output in a widget's bool event (QEvent *event) override and filter to remove the events (by QEvent::Type): Move, Show, Resize, Paint, HoverEvent, HoverMove, Enter, Leave That way, the debug output will only show up for events occuring on mouse click (click and drag for all mouse buttons also works here) 2. trying out the "rebind"-ed button inside the widget. Even if the window is in focus, the widget would normally not get that as a mouse event I tried this out with a QScrollBar of a QTabWidget, because it doesn't have any keyboard events enabled, making it easier to determine