Option for handling axis events outside window area

[dranull]

Describe your PR, what does it fix/add?

Tries to address #3485. Even though it was rejected, I often find myself annoyed by this issue.

So, indeed the mouse coordinates are sent to the application, but they are out of bounds of the window area. Some applications (a terminal) don't really care about this, and can handle it, but in some (browser, text editor, filemanager...) there are specific areas where pointer events are registered, though the coordinates need to be precise.

Most of the time the most important areas are next to the edge of the application's window (like a web-page content or the tabbar in a browser). Based on this fact, this PR adds an option to send a "fake" motionevent to the closest point inside the window area before sending the axis event, which allows the application to register the scroll event.

And it works well, however I marked it as a draft, because I'm not confident if I'm doing it correctly.
Is there a way to fake a scroll event to a specific point on the screen instead of warping the mouse? Or generally a more elegant way to solve this? (Or if this should be in the code at all, however I think it's not possible to do it via scripts at the moment.)

Option name: input:off_window_axis_events

0 - ignores axis events outside of the window area (so over decorations and gaps)
1 (default) - as it works currently (sends out of bound positions)
2 (or anything else other than listed) - fake pointer coordinates to the closest point in the window area
3 - same as 2 but it also warps the cursor

[MightyPlaza]

I think a better way to do this is using decoration flags #3739
that way they can be enabled and disabled for each decoration independently
then, if necessary, create a new option just to disable the scrolling when at the border

gonna add it works for some programs, so I have no idea what the main code status is and whether this is a hyprland bug or not

[vaxerski]

if deco allows input -> send scroll event with a bool return type -> if bool, means deco consumed it.

I wonder if we should also unify the input functions on deco to one, e.g.

bool onInputOnDeco(const eInputType type, std::any data)

and data would be the event pointer

[dranull]

I think I misused the word "decoration", because I mainly meant gaps+border (and as I understand gaps are not considered as decorations), probably the option should be renamed to something like scroll_events_around/outside_window_area.

Properly handling input over decoration which consumes input probably should be done in a separate PR, but as a learning exercise I'll attempt to do it in here (at least the groupbar deco which is in axis event).

whether this is a hyprland bug or not

Not a bug, this PR just tries to add a quality of life tweak.

I wonder if we should also unify the input functions on deco

What then? Should I go in that direction?

Anyway, I was more curious if it's possible to do the cursor warping more elegantly, or even without warping, just sending a wheel event to a specific screen coordinate.

[vaxerski]

What then? Should I go in that direction?

yes, I'd say so.

I still fail to see the point of not sending the events, though. Also, what if someone uses input:follow_mouse as non-0? it's usually about people wanting to scroll outside of the window.

Or should we just keep it as an opt-in

[dranull]

the point of not sending the events

Someone might want that, but it's more like a why not option for completeness, and it's a really cheap few characters long code (if (opt == 0) return;) for a feature.

what if someone uses input:follow_mouse as non-0

Like myself. I don't see how that's related, since only mouse scroll events are intercepted, follow_mouse is dependent on mouse movement.

[dranull]

It's ready for review.

[vaxerski]

wiki mr needed