Open GoogleCodeExporter opened 9 years ago
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
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
... 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
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
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
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
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
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
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
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
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
(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
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
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
Original issue reported on code.google.com by
towom...@googlemail.com
on 17 May 2011 at 7:46