classification
Title: IDLE: scroll text by lines, not pixels.
Type: behavior Stage: resolved
Components: IDLE Versions: Python 3.8, Python 3.7, Python 3.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: terry.reedy Nosy List: cheryl.sabella, miss-islington, terry.reedy
Priority: normal Keywords: patch

Created on 2018-05-28 00:46 by terry.reedy, last changed 2018-06-04 16:46 by terry.reedy. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 7351 merged cheryl.sabella, 2018-06-03 13:16
PR 7397 merged miss-islington, 2018-06-04 15:49
PR 7398 merged miss-islington, 2018-06-04 15:50
Messages (5)
msg317819 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-05-28 00:46
When tk and hence, IDLE, opens a text window, it contains an integral number of lines of text in the base font.  Clicking a vertical scrollbar arrow button moves text up or down exactly one line.  Clicking in the trough between the buttons and and the slider moves text up or down one 'page', a page being the number of lines in the window -2.

The text and window can be de-synchronized with the slider and mouse wheel.  (If the window size is changes to a non-integral number of lines, 'synchronized' means a complete line at the top.)  By default, the wheel moves text about 3 lines per 'click'.  Apparently, it is exactly 50 pixels at a time.  This is discussed on #25015.  For that issue, the focus was on '3' (or 50) being too small. 

This issue is about changing 'about' to 'exactly', so that synchronized text remains so when using the wheel or slider.  For both, the solution should be to use Text.xview_scroll(n, units).

For the wheel, we can replace the default tk wheel handler.  While we are at it, we could make the wheel effect be +- 5 lines, which would solve #25015, which I will close.  I don't think a configuration setting is needed.

For the slider, we can replace xview as the scrollbar command with a function that maps command('moveto', fraction) to xview_scroll(n, 'units').  The number n should be the difference between the current top line
  ("text.index("@0,0").split('.')[0]")
and the desired top line
  ("round(fraction * text.index('end').split('.')[0]").
Experiments should show if we need to adjust the rounded value 

We should not need to adjust for the fact that the last <window-size> lines of text cannot become top lines.  A request to scroll 'too far' goes as far as possible without raising an exception.
msg318662 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-06-04 15:48
New changeset d49dbd9acc6db544ca6cb2445fe17eb0c3be4bba by Terry Jan Reedy (Cheryl Sabella) in branch 'master':
bpo-33664: Scroll IDLE editor text by lines (GH-7351)
https://github.com/python/cpython/commit/d49dbd9acc6db544ca6cb2445fe17eb0c3be4bba
msg318664 - (view) Author: miss-islington (miss-islington) Date: 2018-06-04 16:05
New changeset cfc12ec68c3f90ebd94bc47d14d18b7217850391 by Miss Islington (bot) in branch '3.7':
bpo-33664: Scroll IDLE editor text by lines (GH-7351)
https://github.com/python/cpython/commit/cfc12ec68c3f90ebd94bc47d14d18b7217850391
msg318667 - (view) Author: miss-islington (miss-islington) Date: 2018-06-04 16:13
New changeset db222296871765d76dedb06cace8fa393678ae56 by Miss Islington (bot) in branch '3.6':
bpo-33664: Scroll IDLE editor text by lines (GH-7351)
https://github.com/python/cpython/commit/db222296871765d76dedb06cace8fa393678ae56
msg318675 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-06-04 16:46
I checked that with the patch, the wwindow top stayed synchronized with the text after multiple movement operations of different types.

The minimum requirement for correct operation of the scrollbar slider is that moving the slider to the top and bottom of its trough moves the text to the top and bottom of the file.  Before merging, I checked with editor.py, about 3000 lines, and a new editor with just a couple more lines than the window size.

It is desireable that each pixel movement of the slider move the text.  This requires that there be at least as many hidden lines in the text as there are exposed pixel in the slider trough.  I don't know that this will always be true on all systems.   As near as I could tell with editor.py, which meets this requirement, moving the slider a pixel away from top or bottom also moved the text.  (I can't move a single pixel, so it was more a matter that moving 2 or 3 pixels made 2 or 3 jumps ;-)

I considered these tests enough for now to merge.
History
Date User Action Args
2018-06-04 16:46:53terry.reedysetstatus: open -> closed
resolution: fixed
messages: + msg318675

stage: patch review -> resolved
2018-06-04 16:13:45miss-islingtonsetmessages: + msg318667
2018-06-04 16:05:27miss-islingtonsetnosy: + miss-islington
messages: + msg318664
2018-06-04 15:50:34miss-islingtonsetpull_requests: + pull_request7024
2018-06-04 15:49:32miss-islingtonsetpull_requests: + pull_request7023
2018-06-04 15:48:24terry.reedysetmessages: + msg318662
2018-06-03 13:16:15cheryl.sabellasetkeywords: + patch
stage: test needed -> patch review
pull_requests: + pull_request6978
2018-05-28 02:28:02terry.reedylinkissue33610 dependencies
2018-05-28 00:52:49terry.reedylinkissue25015 superseder
2018-05-28 00:46:46terry.reedycreate