11:00 <WhyNotHugo> When I scroll with touch-and-drag on less, the text follows my finger as I move along (e.g.: if I move my finger 4cm, the text moves 4cm).

11:00 <WhyNotHugo> However, on senpai, if I move my finger 4cm, the text moves like 8cm.

11:01 <WhyNotHugo> Do both less and senpai get the same events from the terminal?

11:02 <WhyNotHugo> Scrolling with `less` works even if I don't pass `--mouse` (and unset $LESS). So it seems that it handles touch-scrolling via some mechanims that _is not_ mouse events...?

12:06 <rockorager> WhyNotHugo: less might be setting alternate scroll mode (DEC 1007), which reports mouse scrolls as arrow presses

12:07 <rockorager> Tcell doesn't set that mode

12:52 <WhyNotHugo> So setting alternate scroll mode would result in touches sending arrow presses and scrolling the right amount... but would the client (e.g.: senpai) know _where_ the touch ocurred?

12:53 <WhyNotHugo> As per https://codeberg.org/dnkl/foot/pulls/137, I think `less` doesn't set this by default

12:54 <WhyNotHugo> From the issue: > alternate scroll mode is implicitly disabled, temporarily if you like, while an application is grabbing mouse events

12:55 <WhyNotHugo> The question is: can we enable alternate mode while the applicaiton is grabbig mouse?

12:58 <dnkl> WhyNotHugo: in short, alternate scroll translates mouse events to arrow key events. It's only used on the alternate screen, and only when the application hasn't enabled mouse events.

12:59 <dnkl> when the application has enabled mouse events, it receives the "raw" number of scrolled lines. I e the multiplier from foot.ini is not applied

13:00 <dnkl> don't remember if we apply the multiplier to alternate scroll

13:00 <WhyNotHugo> When I touch-drag an application, foot sends mouse events that scroll an amount disproportionate to the amount of finger-movement.

13:00 <WhyNotHugo> With alternate mode, the amount of "arrow key presses" is correct, so the amount of scroll is correct.

13:01 <WhyNotHugo> So I guess that the issue is really in how touch-events are translated to mouse-scrolls in non-alternate mode?

13:02 <dnkl> WhyNotHugo: I'm guessing you don't want the multiplier applied. Or rather, we should have a separate multiplier for touch events

13:04 <WhyNotHugo> I think that sounds correct.

13:06 <dnkl> except, senpai does enable mouse events. So it should be senpai that's multiplying the amount is scrolled lines in this case

13:11 <WhyNotHugo> When I use the mouse wheel, it scroll the right amount. And senpai can't know if I'm using a wheel or touchscreen, so I think that the multiplier needs to happen in foot (which does know).

13:14 <dnkl> WhyNotHugo: this needs to be tracked and discussed in an issue. If we are to apply a multiplier option for touch events, even when mouse grabbing is enabled, that'd be a different behavior, compared to normal mouse events. For example, does that mean we need to touch multipliers? One that corresponds to the existing one, and another for when mouse grabbing is enabled?

13:22 <Amnesia> question; how exactly are you guys starting the foot server (if you even are using server mode)?

13:22 <dnkl> WhyNotHugo: btw, what's the "right" amount? For me, senpai scrolls 4 lines for each mouse wheel "click".

13:22 <dnkl> Amnesia: dinit user service

13:22 <Amnesia> currently I've put it in my sway config; because when I use the systemd service/socket; it fails to start because the wayland socket isn't available yet :X

13:23 <Amnesia> TIL the dinit init system

13:26 <WhyNotHugo> dnkl: I'll open an issue for this.

13:27 <dnkl> WhyNotHugo: in any case, it's important to realize senpai multiplies the number of lines. While it should probably be considered a bug if touch-scrolling a line results in a different number of events being sent to the application, compared to regular mouse scrolls, senpai is still a bad way to test things. It's better to test in an environment where there's no multiplier

13:33 <WhyNotHugo> Changing the multiplier in senpai to "1" results in only one line scrolling at a time...

13:33 <WhyNotHugo> ... However, when I move the mouse wheel "one click", it now scrolls just one line, whereas it scrolls three on a terminal.

13:50 <dnkl> WhyNotHugo: this behavior (not applying the multiplier to mouse events) has been discussed before, on the issue tracker

13:51 <dnkl> what it comes down to is this: the application must have full control over the events. There's no way for the application to scroll a single line if foot forces three lines. Most applications that supports mouse scrolling do expose their own multiplier option.

13:53 <WhyNotHugo> I can hardcode any multiplier that I want for senpai, but there is no correct value.

13:53 <WhyNotHugo> I want 3x for mouse-wheel and 1x for touch (e.g.: like on non-mouse-capturing applications).

13:53 <WhyNotHugo> But senpai cannot distinguish the two.

14:14 <dnkl> WhyNotHugo: in a sense this is unsolvable, and comes down to touch not really existing in the terminal world. Basically, what you're asking for, is a ¼ multiplier, to counteract senpai's mouse multiplier.

14:27 <WhyNotHugo> Could foot apply a multiplier itself before sending mouse scroll events?

14:27 <WhyNotHugo> Or is this too likely to break other tools?

14:47 <rockorager> WhyNotHugo: Does less have the correct behavior right now?

14:47 <rockorager> 1 line on touch, 3 lines on mouse wheel?

14:52 <rockorager> dnkl: does foot receive different wayland events for mouse scroll vs touch scroll?

14:52 <rockorager> Or does libinput map touch scrolls already....?

14:52 <rockorager> What about scroll direction??

14:57 <WhyNotHugo> rockorager: Yes, less behaves correctly (e.g.: text moves under the finger when touch-dragging, but scrolls 3 lines with mouse-wheel).

14:58 <rockorager> also foot.ini.multiplier I assume *only* applies to foot scroling (IE history)?

14:58 <WhyNotHugo> foot has native support for pointer vs touch inputs, so receives different events from the compositor.

14:59 <WhyNotHugo> (FYI: converting touch events into mouse events is done by the compositor, and is only done for clients that do not handle touch events themselves).

15:02 <rockorager> How is less doing this??

15:03 <rockorager> I see CSI < 64 ; col ; row M for both my touchpad and mouse wheel but somehow less knows

15:06 <rockorager> Oh I get it

15:07 <rockorager> When an application *doesn't* capture mouse, foot is applying multiplier to mouse wheel but *not* scroll

15:08 <rockorager> echo -e "\x1b[?1007;1049h" && cat -v

15:08 <rockorager> (warning, will leave you in alternate screen)

15:09 <WhyNotHugo> I'm pretty sure that a touchpad counts as a pointing device, not a touch device.

15:09 <WhyNotHugo> Because when you tap on the touchpad, it's just a tap, not a tap with X and Y coords.

15:09 <dnkl> yes, all three are different Wayland events (mouse, touchpad, touch)

15:10 <rockorager> If I do less --mouse it only moves one line for any scroll event

15:10 <rockorager> Which means less doesn't apply any internal scrolling multiplier

15:11 <WhyNotHugo> If you use `--mouse`, then it does mouse-capturing, which is what senpai does.

15:11 <rockorager> Right

15:11 <WhyNotHugo> If you apply that internal multiplier, then touchscreen-dragging will over-scroll.

15:12 <rockorager> So the current state is that you can't capture mouse and emulate "standard" terminal scrolling size and *also* have good touch scroll support

15:14 <rockorager> we need a new mouse button number

15:18 <rockorager> scroll-down is mapped to 64, up to 65, we could probably use 66 and 67 for touch scroll down and touch scroll up

15:18 <rockorager> In a sense, we need terminal gesture support

15:18 <rockorager> three finger swipe left = CSI < 68 M

15:18 <rockorager> :)

15:22 <dnkl> 66 and 67 are for wheel left/right ;)

15:23 <rockorager> who has that insanity? But ok, 68+

15:23 <dnkl> for those interested; less has a command line option to set the scroll multiplier

15:24 <dnkl> the button logic is s bit more complicated than that, but yes, it would be possible to extend the protocol with touch specific events

15:26 <dnkl> I'm guessing we'd get pretty far with just being able to configure senpai's multiplier. people who use touch primarily can tune it down

15:26 <rockorager> dnkl: yeah

15:28 <rockorager> But who doesn't want gestures in their terminal?

15:29 <rockorager> I could map a three finger swipe right to ':wq!'

15:31 <Lord> i use foot on my phone ;-)

15:32 <rockorager> Oh I guess we'd need pinch events too?

15:32 <rockorager> Probably for a terminal that should just always map to font size changes

15:33 <Lord> that would be great !