Application mouse scrolling doesn't always work with scrollbar enabled

[GoogleCodeExporter]

Hi Andy,
I came across this problem and remember that we exchanged some mail about it 
before: in mouse application mode, mouse wheel events are not reported to the 
application (all other mouse events are); if the scrollbar is switched off, it 
works.
From http://code.google.com/p/mintty/wiki/CtrlSeqs, I am not quite sure what 
the purpose of "Application mousewheel mode" (7787) is; it doesn't help anyway.
Best regards,
Thomas

Original issue reported on code.google.com by towom...@googlemail.com on 17 May 2011 at 7:46

[GoogleCodeExporter]

This seems to be dependent on the mouse driver. It works fine on my desktop 
with a generic USB mouse, but not on my laptop with a Synaptics touchpad.

Where it doesn't work, the mousewheel events are never delivered to the window 
in the first place, as apparently the disabled scrollbar on the alternate 
screen is taken to mean that the window can't scroll anyway. Not entirely 
unreasonable, but also rather preemptive.

Since mintty never gets those mousewheel events, I have no idea how to address 
this. Leaving this open for documentation purposes, but with priority None.

Application mousewheel mode allows an alternate-screen application to 
distinguish mousewheel events from cursor up/down events without enabling full 
xterm mouse reporting.

Original comment by andy.koppe on 18 May 2011 at 7:25

• Changed title: Mouse scroll application mode does not always work with scrollbar enabled
• Added labels: Priority-None
• Removed labels: Priority-Medium

[GoogleCodeExporter]

It would help to implement a save/restore feature so that the application can 
explicitly disable the scrollbar and later restore its previous state.
xterm describes CSI ? Pm s and CSI ? Pm r for this purpose.
So ESC[?30s ESC[?30l ...(application acting)... ESC[?30r would fix the 
situation.
Note that this does not work in xterm (as described... - I think I even sent 
him a bug report already) but it would still help to be able to use it in 
mintty.

Original comment by towom...@googlemail.com on 26 May 2011 at 2:09

[GoogleCodeExporter]

... or even better, actually, to disable the scrollbar implicitly whenever the 
"alternate screen buffer" is enabled as it is of no use then anyway.

Original comment by towom...@googlemail.com on 27 May 2011 at 7:44

[GoogleCodeExporter]

I've entered issue 267 for the private mode save/restore sequences. Thanks for 
the reminder. Meanwhile, you could just use '\e[?30l' and '\e[?30h', because 
the enable sequence will only show the scrollbar if the user allowed it in the 
mintty options.

Automatically removing the scrollbar when switching to the alternate screen 
would require either to change the window size or the terminal size. Making the 
window narrower would be rather annoying, particularly if you've carefully 
lined up your windows in some way. Increasing the number of columns would still 
leave an ugly border on the right edge, depending on how character width and 
scrollbar width happen to match. Also, it would mean a SIGWINCH early in the 
startup of an application, which could easily get lost or otherwise confuse an 
application. I've tried it, and 'nano' gets itself into a really bad state 
where it keeps on switching back and forth between the primary and alternate 
screens.

Original comment by andy.koppe on 28 May 2011 at 5:38

• Changed title: Application mouse scrolling doesn't always work with scrollbar enabled

[GoogleCodeExporter]

I see.
Thanks for the hint with the constrained scrollbar enable sequence; however, 
it's not usable right now because it's not symmetric:
Disable will remove the scrollbar and make the window narrower.
Enable will add the scrollbar but not make the window wider.
So the effective terminal screen size is reduced every time the application is 
called...

Original comment by towom...@googlemail.com on 30 May 2011 at 2:34

[GoogleCodeExporter]

I don't see that when simply echoing the sequences on the command line, either 
on the primary screen or the alternate screen.

Original comment by andy.koppe on 31 May 2011 at 5:08

[GoogleCodeExporter]

You're right. It's some weird interaction with mined which does an explicit 
screen resize as a workaround for some older versions of xterm on cygwin and 
SunOS where neither the terminal nor the tty reported the actual screen size 
properly...
(So what happened is probably that mined resized mintty to the size detected 
before the scrollbar was turned off - which I can easily fix.)

Which made me reconsider the screen resize approach you described.
From an application point of view, it can be considered surprising that the 
effective terminal screen width changes if the scrollbar is toggled. Also it is 
not what xterm does here. Just for consideration...

Original comment by towom...@googlemail.com on 31 May 2011 at 10:12

[GoogleCodeExporter]

I was aware that xterm and rxvt (which is where it originated) handle the 
scrollbar sequence differently, but acceptedd this minor incompatibility, 
because I think that changing window size would be more annoying. Also it's not 
what Windows applications generally do.

However, since mintty does have slightly different semantics here, I suppose I 
should actually make this a mintty private mode. Mined doesn't actually use 
this yet, does it? So would you be if this moved to, say, 'CSI ? 7766 h/l'? I'd 
leave a properly compatible implementation of 'CSI ? 30 h/l' for later.

Original comment by andy.koppe on 1 Jun 2011 at 5:51

[GoogleCodeExporter]

I agree with the private mode. Mined cannot easily use it, though, as it gets 
confused apparently by WINCH at this time as well (which I should fix 
anyway...).

About the compatible DECSET implementation: What about switching to a "fake" 
scrollbar in order to avoid resizing of the window? I.e. disable the scrollbar 
towards Windows and its drivers so the mouse wheel can work, and paint a gray 
scrollbar look-alike instead.

Original comment by towom...@googlemail.com on 1 Jun 2011 at 7:57

[GoogleCodeExporter]

Right, I've moved the scrollbar hiding from private mode 30 to the 
mintty-specific private mode 7766, in r1192.

I'd pondered the "fake" scrollbar idea too, but there are two problems with it, 
apart from the work involved: it doesn't work when trying add a scrollbar if 
there wasn't one to start with, and it wouldn't take themes into account, so it 
would stick out like a sore thumb on most systems.

Hence I've looked at the implementation of private mode 30 elsewhere again. I 
still don't agree with changing the window size as done in xterm, rxvt, and 
rxvt-unicode. The effect on a maximized window is particularly lamentable, 
which I think makes this sequence practically unusable for applications. 
Meanwhile, KDE Konsole and GNOME Terminal simply ignore it, so mintty shall do 
the same.

Original comment by andy.koppe on 1 Jun 2011 at 7:54

[GoogleCodeExporter]

Yet another way to work around this might be to allow alternate screen 
applications to activate the scrollbar and take control of the scrollbar range, 
size, and position. Scroll events could then be reported to the application 
using a to-be-determined control sequence.

The main problem I can see with this, apart from the fact that applications 
need to be specially adapted to take advantage of it, is that the terminal's 
scrollbar covers the whole height of the window, whereas applications usually 
have a menu and/status line at the top and bottom, i.e. the scrollbar wouldn't 
quite line up with the actual text area. Thomas, would you find that worthwhile?

Original comment by andy.koppe on 11 Jun 2011 at 10:27

[GoogleCodeExporter]

(Note to self: automatic scrollbar hiding could be done quite simply by 
dropping SIF_DISABLENOSCROLL from the SetScrollInfo() call for updating the 
scrollbar.)

Original comment by andy.koppe on 11 Jun 2011 at 10:32

[GoogleCodeExporter]

This proposal sounds interesting. I am undecided though whether it's worth the 
effort. A mismatch of 1 top and bottom line would not be fatal to the idea, I 
think. However, it should be possible to have the interaction more or less 
compatible to other terminals / self-made mouse control. Maybe the control 
sequences should be just the same as are expected now in application mouse 
mode, just adding scrollbar layout control. Could mouse position coordinates be 
included as they are now, actually? Otherwise the value of this mode would be 
quite limited.
And what would be the effect of the feature you mention in comment 12?

Original comment by towom...@googlemail.com on 20 Jun 2011 at 1:10

[GoogleCodeExporter]

Applications would need to be adapted to set the scrollbar range, size, and 
position anyway, so I don't see any particular value in the scrolling messages 
being compatible with xterm mouse reporting. Furthermore, the scrollbar may 
cover a range of many thousands or even millions of lines, where sending 
line-by-line scrolling events when dragging the scrollbar would be far too slow.

Reporting mousewheel events with existing sequences would make sense, but on 
systems affected by the issue here, Windows reports mousewheel turns as 
scrolling events when an active scrollbar is present, and I don't know of a way 
to distinguish them from scrollbar drags.

Comment 12 is about automatic scrollbar hiding as discussed in comments 3 and 
4, with the attendant SIGWINCHs at unopportune times. I'd noticed that Windows 
makes it quite straightforward to implement, but it's still just as problematic.

Original comment by andy.koppe on 23 Jun 2011 at 6:04