New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[enhancement] Stop pointer from crossing output boundaries #1699
Comments
I know this gets requested a lot, but I don't think this belongs in i3 because of how weak the use case is. Any app that needs this, such as a game, should already be implementing it themselves. For anything else, just be more careful with your mouse. I think it takes less mental effort to do that than to remember to press a button every time you want to click something some small distance from the border of the outputs. |
Yes, by grabbing the pointer and confining it to the window, I suppose. Unfortunately I can't write an external tool that just grabs the pointer the entire time (not in any sensible way anyway).
Easier said than done. :/ |
I don’t see why it would be simple to handle in i3 but impossible in an external tool. Can you elaborate on that? |
If we do it in i3, we have control over the motion notify event and how i3 processes it. In particular, i3 can choose to not switch focus and warp the pointer instead. In an external tool, I can only warp the pointer when it's "too late", i.e. when there already is a motion notify in the queue that puts the cursor on the other output. Since the tool can't tell i3 to not process it, i3 will switch focus and then switch it back after the tool warped the pointer which both disturbs focus order and is glitchy graphically. Even worse, with mouse warping enabled in i3, the pointer will jump in completely unexpected ways. I have a small program for this if you want to try it out yourself. |
Maybe you are warping too late. Try using a buffer of a few pixels. |
That won't work reliably because X makes no guarantees on how often motion notifies are sent. It could be every pixel or it could be none at all until the pointer comes to a rest. And from my tests I can tell that it's not unlikely at all that going anything but slow with the mouse will cause the event to be more than a few pixels off. But the usecase definitely includes just flicking the mouse out of the way. |
I think I understand where you’re coming from, but I’m not convinced having this feature would be worthwhile. See also https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/ My current recommendation is to either be more careful with your input devices, get better input devices or both :). |
OK with me. It's an annoyance for me, but as long as I'm alone, I understand the reasoning. |
@stapelberg, @acrisci you're basically writing off potential users of i3 who 1) play games and 2) display more than one window at a time. That's got to be a pretty large fraction. cc @Airblader |
Has this issue being reconsidered? Sure, in an ideal world applications would implement this themselves. Unfortunately we do not live in that world, so the current options we have are:
Seems to me like number 5 is the better option. As @Mori mentioned, not doing so pretty much writes off a significant part of Linux users. |
Personally I did end up no longer needing this, though obviously I can still understand why people would. Having worked on xedgewarp, which does sort of the opposite of this, though, I have a slightly different feeling about implementing this in i3. On the one hand, yes, it would make it much easier to implement functionally than in an external tool, but even so I think the implementation would still feel pretty workaround-ish as there is no true way of preventing the cursor to move across outputs. We'd end up warping it and this is surprisingly tricky to get right in a way that feels really clean. Apparently I stated other WMs can do that, so we could check how they actually do it (maybe I'm missing something). However, I also think there's a straight-forward way to solve this on the user side independent of the WM: just don't configure your outputs to be next to each other, but vertically offset so they don't share edges. Example:
That way the X server will take care of the problem. The only downside I could think of right now is |
I'm using the workaround you suggested for the time being but it feels incredibly hacky, honestly. I'd like to explore a more elegant way of solving this issue, if possible. |
When using multiple outputs, I usually want to stay on one workspace unless I specifically want to switch in which cases I usually rely on mouse warping anyway.
However, I find myself using the mouse out of the way a lot. Especially if I fullscreen a window. But also, for example, if I need to click something in the workspace / statusbar, it can easily happen that I "overshoot".
Given those usecases, I'd love to have a feature to specify a modifier key. If it is set, the mouse will only cross output boundaries if that key is pressed.
I'd like to point out that I tried to implement this as a separate tool. However, I can't find any way of preventing the mouse to ever move to the other output – I can only warp it back. But that means i3 will receive a motion notify which will cause focus to switch to the second output and then back to the first. If mouse warping is activated, this also causes i3 to warp the pointer into the middle of the focused container on the first output.
I'd assume this to be a fairly small change, so I'd love to see this accepted. If anyone has an idea to properly implement this as a separate tool, I'll be happy to do that, too, though.
The text was updated successfully, but these errors were encountered: