GNOME Bugzilla – Bug 424184
Make scroll wheel send Page Up/Down when it makes sense
Last modified: 2007-04-06 15:31:59 UTC
I'm attaching a patch that makes vte send Page Up/Down when it gets a scroll event and it's currently using alternate_screen. As far as I can tell, alternate_screen is used for terminal apps like emacs, vi, and less, which write to the entire screen. When alternate_screen is being used, the scrollbar is basically useless. The idea is that the terminal can't scroll for these applications, but many such applications can scroll internally with Page Up/Down. So instead of trying (and failing) to scroll the scrollbar, we just simulate a Page Up/Down key press. It was mentioned on IRC that perhaps we should send Up/Down instead of Page Up/Down. I think Up/Down actually feels nicer when using a pager, but it's kind of weird when using an editor. Page Up/Down do scroll pretty fast though, so maybe it should be changed to Up/Down. I don't know if the patch is completely right. I don't really know how the keymap stuff works, and I just copied some code from vte_terminal_keypress. For all I know, my patch could be horribly broken on every machine but mine. Somebody who understands terminal emulation better should carefully check what I'm doing. That said, this patch does work for me.
Created attachment 85520 [details] [review] Send Page Up/Down to alternate_screen for scroll events
More thoughts on whether to send Page Up/Down or just Up/Down: Just sending Up/Down feels like it scrolls much slower than I would expect my scroll wheel to scroll. But sending Page Up/Down really flies through the document, as most of these applications seem to scroll an entire screen-full. Perhaps we can get a nice middle ground by sending Up/Down multiple times, perhaps some percentage of the current screen height. I think this approach would probably produce the best results. One problem, however, is that terminal applications like to beep when you hit Up/Down at the top/bottom of their buffer. So if I'm three lines short of the bottom of a file and scroll down, and vte then sends 15 Down key presses, I'll have to listen to 12 beeps. And that would be mighty annoying. But don't these applications beep by "printing" the character 0x07? And doesn't vte receive that? So maybe it's possible to do something like: for i from 1 to some_number: if we_just_beeped(): break; send_up_or_down There's a good chance that I'm over-engineering this.
Just for reference, the default behavior for the scrollbar in most windows is to scroll about 4 lines for each scrollwheel click (although it may be configurable, I don't know). So sending 4 ups or 4 downs would probably result in the behavior that's most consistent with user expectations. That said, I also think that sending multiple keypresses sounds a bit ugly.
Created attachment 85522 [details] [review] Sending multip GDK_Up or GDK_Down I've tried this patch with GDK_Page_Up/Down, and GDK_Up/Down. Sharing same thought s with Shaun. Now I'm calling vte_terminal_feed_child_using_modes() three times, and now it's a lot more better at least that's the default scroll action I get. Unfortunately my terminal bell is not working somehow (luckily, I always end up disabling it anyways) so that I could not see bell action. But it's still good point that catching multiple bell instances for close intervals. It's not only this scroll event, but for a regular terminal user (or at least for me) pressing keys multiple times is not a rare event. That's why I mostly disable bell. Btw, I tried this with visible_bell=TRUE and 14 GDK_Up sending. And for visible_bell, it seems like even though you're on the bottom of a `less` screen, it handles bell only once. So maybe functinality is already there. But there's a good chance that I don't feel multiple bell events with visible bell due to lack of refresh rate of screen. If someone can try patch with his/her bell working then everything seems ok from user level, I guess.
Oh wow. I just tried sending multiple GDK_Up/Down events, and I indeed only get one beep for each scroll event, no matter how many key events it sends. I don't know what magic makes that happen, but I like it. So yeah, I think the best option is to choose some number and send GDK_Up/Down that many times.
I was resisting applying this patch before 0.16.1 - however it is too good to ignore... Thanks. r1864: 2007-04-04 Chris Wilson <chris@chris-wilson.co.uk> Bug 424184 – Make scroll wheel send Page Up/Down when it makes sense Original patch by Shaun McCance and refined by Baris Cicek. * src/vte.c (vte_terminal_scroll): Send cursor keypress instead of trying to scroll the alternate screen in vain.
3 is fine. Another option would be one-tenth of the number of the rows. That's what g-t does for scroll wheel these days... Maybe add an API that g-t can call in, to make sure both use the same number of lines..
Indeed, I chose to use the same number of lines as computed for the normal scrolling.
Created attachment 85907 [details] [review] Calculating scroll from terminal rows It's easy to calculate 1-tenth of the rows using terminal->row_count / 10, but isn't it too small for a jump even for normal whell action. It should be atleast 1-eighth so that it would be three lines for default g-t screen. Re-opening bug for that reason.
Well I can't re-open, maybe someone does.
Ok, a couple of points: - you submitted a fresh patch against an old revision; - the patch that I actually applied used the same MAX(1., ceil (page_increment/10.)) as the normal scrolling.
Yes, I did not check last revision from svn, sorry. terminal->row_count and adj->page_increment holding same value so patch should be ok anyways. I just thought it was using static number due to Behdad's comment, it must be posted after commit.