[Bug] Cannot click small targets on inactive slightly-offscreen windows

[rrastgoufard]

Hey! Love this project and have been using it extensively on multiple devices for the past few months. Really, truly love everything here.

I've been finding myself wanting to click on buttons on inactive slightly-offscreen windows. What happens is that the window will gain focus immediately upon mouse press, then the window will move, and then the mouse release will no longer be on the button, causing the action to have not worked.

Attached is a screenshot of two firefox windows. The one on the left has focus currently, and I want to click the close tab button on the window on the right. (The mouse cursor is hovering over it in the screenshot.) In this layout, that close button cannot be clicked.

This happens both on X11 with a mouse and on Wayland with a touchscreen. For the focus mode, I am using click-to-focus and not focus-follows-mouse.

[peterfajdiga]

Hi, thanks for the report! This is something that annoys me as well, but there's no nice way to solve it.

I wish I could check the state of the mouse button and wait for release before scrolling to the newly focused window, but the Kwin Scripting API doesn't provide this.

One solution that I see is that I could add a delay after a window is focused, before scrolling to it. This could help in some cases, but not all (depending on how long the user takes between pressing and releasing the mouse button). But this delay would also apply when changing focus with the keyboard, and that's something I don't find acceptable.

[rrastgoufard]

Is it possible to determine whether a focus change was triggered via a shortcut as opposed to other means? If so, that would help greatly, as we could add the delay only in cases when no shortcut was triggered.

[peterfajdiga]

Nope, except Karousel's own shortcuts. But like I said, this solution wouldn't be bulletproof anyway, because the amount of delay would be just a guess.

[rrastgoufard]

Wait, I almost never use shortcuts other than karousel's own for changing focus. We're talking about things like alt-tab, right?

I would love a configurable delay (that could be set from 0ms to 1000ms or something, with default set to 0ms) in the script settings that only applies when focus changes due to non-karousel shortcuts. When a karousel shortcut is invoked, no delay! :)

You're right that this isn't bulletproof, but I think it would almost entirely solve my issues without negatively affecting the current behavior at all because we set the default to be 0ms.

What do you think?

[rrastgoufard]

Hey again! I had a new thought -- in addition to a timer, it would be great to be able to disable all grid movement completely when not using a designated karousel shortcut.

Just tried karousel on a two side-by-side monitor setup, and I really want to interact with the windows on the "other" monitor but can't because they snap to "this" monitor as soon as a click gives them focus. (BTW, love the shortcut for designating "this" monitor as the grid's center. It's fun to move the grid around the screens.)

I realize the dual-monitor usage is not what originally sparked the idea to add a timer and/or lockout when not using karousel shortcuts, but I think adding that would potentially solve many issues.

[peterfajdiga]

@rrastgoufard

Hey again! I had a new thought -- in addition to a timer, it would be great to be able to disable all grid movement completely when not using a designated karousel shortcut.

But when using a Karousel keyboard shortcut for moving focus, scrolling would still happen and it would still be annoying, if your current focused window is on another monitor. I wish there was a way to pin windows to a single monitor (and prevent them from showing up on other monitors), but without it, Karousel just can't really work with multiple monitors. :(

[rrastgoufard]

You're definitely right that if I use a focus-changing karousel shortcut, the grid would move and it would be weird that the movement would be linked to only 1 monitor. But without shortcuts, I can still click on offscreen windows to interact with them, and if I need to look at windows that are not currently on the screen (they are farther off the karousel grid), I can always use the karousel-scroll-grid shortcuts.

I'm still of the opinion that a small delay-movement-on-focus-change timer which we originally discussed would be good, and allowing the delay to be infinite would also be good.

--

This issue wasn't exactly intended to be about multiple monitors, but I have some thoughts in case you're interested in considering them. Probably not all of them (maybe even none) are 100% possible, but I'm not against making these changes to get us closer. Having possible workarounds is better than having it not possible I think.

There are three monitor layouts I can think of that are relevant to discuss with karousel. 1) Side-by-side monitors, that is, monitors that go left to right, that we want a single karousel grid to span. 2) Vertical monitors where we want a karousel grid only on one monitor 3) Side-by-side monitors where we want the grid ONLY ON ONE monitor and not the other.

Arrangement 3 I think is not easily possible. I recall a discussion about PaperWM in one of the issues on this github where gnome allowed for clipping boxes that hide contents outside of them.

Arrangement 2 I think currently works! Any window you want in the grid is already in the grid, and any other window can be floated and placed on the other monitor. Since the grid moves left to right, it does not affect anything that is vertically above or below it.

Arrangement 1 currently works, but only visually! I can SEE the grid correctly spanning the side-by-side monitors and moving naturally. But when I interact with a window that is not on the "primary" monitor, it forcibly snaps to the primary monitor.

If we implement this issue request's ability to disable grid movement on focus change, then I could interact with a window on another monitor that is still in the karousel grid as long as I don't use specific karousel shortcuts.

This is, as stated previously, definitely a workaround and not a true solution. But if you decide to add a delay to solve the original issue, allowing that delay to be infinite would coincidentally allow me to workaround using side-by-side monitors arrangement 3 above.