Application Scrollbar Mode

[scandum]

There appears to be a bug where the scrollbar loses track of the position it reports. It's fairly easy to reproduce.

echo -e "\e[100;100;1#t"

Grabbing the scrollbar it reports:
\e[100#d
Slide up and down while keeping the button pressed down, and when you return to the starting position it will report a semi-random value between 95 and 100, rather than 100.

I assume it's a rounding error where mintty calculates the new position based on the current position, rather than the absolute position.

Another issue is that the scrollbar jumps back to the end position if you release the button halfways up. This can be fixed by echoing back the position with \e[#d, but this seems unnecessary as well as a recipe for infinite loops.

An option to set the color of the scrollbar could be a nice addition. Something like \e[31;46#m, to set the foreground to red and background to cyan, 256 and truecolor support would be great as well.

[BrianInglis]

You'll find the previous mention issue #751 marked as insane difficulty, soliciting implementation patches.
IIRC Windows currently doesn't easily allow any scrollbar customization, except perhaps as part of a theme, possibly for accessibility, security, and visibility reasons.
So custom scrollbars have to be emulated and themes supported by a user-draw control reproducing all the scrollbar functionality itself!

[mintty]

\e[100#d

is reported for me consistently at the bottom, I cannot reproduce your observation.

the scrollbar jumps back to the end position if you release the button halfways up. This can be fixed by echoing back the position with \e[#d, but this seems unnecessary as well as a recipe for infinite loops.

This is on purpose and is just dedicated to prevent any loops. The position must be set only by the application, as implicit setting would in turn trigger additional reports.

[scandum]

It occurs very consistently for me. Keep in mind it will jump to 100 when you release the scrollbar at the bottom, but prior to that it's often misaligned. Screen size of 24 rows.

As for loops, I think you're mistaken, but rather than argue, could you add an escape code to set an option to enable implicit confirmation?

[scandum]

Heck, and while at it, an option to make the scrollwheel events generated universal across the terminal, unless mouse tracking is enabled.

[mintty]

What I see is occasional incomplete delivery of the escape sequence while the button is still held, like ^[[85#d^[[10 and 0#d appended when moving further or releasing the button. This could cause the effect you observe.

About immediate scrollbar synchronization: I had tried that, it caused trouble.
About reporting: you mean also when the mouse is not over the scrollbar? Windows provides different messages in that case, as the scrollbar is considered a special interaction paradigm, so I hooked only into the scrollbar events. Probably possible though.

[mintty]

I've uploaded an attempt to nudge the complete delivery of application scrollbar sequences. Please try whether that solves the "100" issue.

[scandum]

The most recent build still seems to have issues, and scrolling stalls if you move the scrollbar too quickly.

I can provide you with a working implementation if you want to see for yourself. Might save us some back and forths and aid you in debugging.

As for synchronization, I guess it's not a huge issue. Might want to more clearly document this.

As for reporting, that's correct, the default scrollwheel behavior of mintty isn't particularly useful in custom scroll modes.

[mintty]

I can provide you with a working implementation if you want to see for yourself.

Yes please, if you have something, show me.

I don't quite understand the last two sentences.

[scandum]

I put up a beta version, to install:

wget https://mudhalla.net/tintin-beta.tar.gz
tar -zxvf tintin-beta.tar.gz
cd tt/src
./configure
make install

For testing it's probably easiest to create a small script file, place the following text in a file named scroll.tin

#split 3 3
#screen scrollbar on
#event {SCROLLBAR UPDATE} {#draw Green tile 2 2 2 8 %0;#draw Green tile 2 9 2 16 %1}
#event {SCROLLBAR POSITION} {#draw Magenta tile -3 -8 -3 -2 %0}
#help %*

To run it:

tt++ scroll.tin

The bottom right shows the scrollbar position as reported by mintty. The upper left shows the scrollbar position as reported back by tintin.

As for synchronization, the biggest issue I ran into is that tintin's idea of a scrollbar is slightly different from that of mintty.

Right now I'm using an approximation that seems to work well enough, but a clear description of how the application scrollbar is supposed to behave might be helpful, and to really handle it perfectly seems tricky.

I also notice a stutter when using the right click 'scroll here' scrollbar option. Looks like mintty jumps to the location, reports, jump back, then jumps back to the location once it gets the confirmation. I could see this becoming a more prominent issue when using the feature remotely.

[mintty]

The position refers to the upper end of the viewport, that might cause some confusion. So if for example you set up
echo -e "\e[50;100;10#t", the marker on the scrollbar will not be in the middle, but its upper end will be. The maximum line number reported in this case will be 91, not 100, as it also reports the position of the upper end.

[scandum]

I see, tintin measures from the bottom end of the viewport, so that explains some of the trouble I ran into.

I've updated https://mudhalla.net/tintin-beta.tar.gz so it properly utilizes the viewport.

[mintty]

I considered to scale the pos value to match the size value at 100%, but the current way matches the Windows paradigm of scrollbar dimensions unchanged and avoids scaling and rounding effects.

I have improved the feature description and uploaded that to the wiki pages:
https://github.com/mintty/mintty/wiki/CtrlSeqs#application-scrollbar
https://github.com/mintty/mintty/wiki/Keycodes#application-scrollbar-events

[mintty]

Released 3.4.0.