Comment by mrob

20 hours ago

IMO, "scroll here" should be the default action for clicking on a scrollbar. There are already good keyboard shortcuts for page up and page down, but there cannot be a keyboard shortcut for "scroll here". It's wasting the capability of the mouse to duplicate keyboard functionality when you could be benefiting from unique mouse-only functionality.

GTK gets this right, and Qt does not.

Oh hell no. If you think "scroll here" is a sane default, you haven't experienced the pain of jumping possibly thousands of lines in a long document with an accidental click, and no easy way to go back to where you were.

  • I don't think that's a serious problem. There are three possibilities I can think of:

    1. You're editing text outside of Emacs. Your cursor remains where it was, so you insert a single character and the document scrolls back to the cursor. You can then delete that character.

    2. You're editing text in Emacs. You like to pretend it's still the 1970s and off-screen cursors are some pie-in-the-sky fantasy. You solve the problem with some unspecified ELISP wizardry, which as a self-respecting Emacs user you are surely capable of.

    3. You're reading a read-only document. You activate your full-text search, which every good document viewer has, and start typing the last sentence you read while it's still fresh in your memory.

  • How about making it configurable system-wide? Except that ain't gonna happen with the insane fragmentation we're seeing in UI libraries

    • At least Mac OS has a global setting for this (oddly placed in the Appearance section):

      Click in the scroll bar to

      (•) Jump to the next page

      ( ) Jump to the spot that's clicked

Mouse and keyboard should be alternatives on equal footing as much as possible. The gutter for page up/down has the benefit that you don’t have to move the mouse all the way up and down to the arrow buttons when repeatedly switching between the same adjacent pages, or when you positioned the scroll button slightly off where you wanted the position to be, and adjust it a little by paging up or down — especially when the scroll range is so long that a small mouse move on the scroll bar corresponds to more than one page.

For scroll ranges that aren’t overly long, you can long-press so that the area ends up scrolling to that position. Only for long scroll ranges is it necessary to drag, use the context menu, or the Shift key, for absolute positioning.

There are certainly trade-offs, but it’s not like there aren’t justified reasons for the way it is.

  • The ubiquity of mouse wheels and two-finger scrolling on trackpads drastically weakens your case for prioritizing the page up and page down behaviors in the scroll gutter. The mouse already offers a low-effort way to adjust scroll position at small to medium scales, generally much easier that repositioning the cursor from above to below the scroll thumb unless you really need to scroll by precisely one page (usually not possible on the web anymore because of floating dickbars).

With regards to Qt, does that mean Qt apps on Windows or something? I use KDE so there are a lot of Qt apps and they are all click-to-scroll in the scrollbar. Of course it's KDE so it's configurable so you can change it to click-for-page-up/down and middle click to scroll, but left-click to scroll is the default.

> IMO, "scroll here" should be the default action for clicking on a scrollbar.

> and Qt does not.

Isn't that what middle click does in Qt?

  • Thanks, that does indeed do "scroll here". Now to figure out how to swap the left click and middle click functionality...

IMHO it should be long hold. Click to jump by a page towards the click location. Hold down to jump all the way there.

  • "Long press" is the same as "slow press". When I click I want something to happen immediately, not 500ms later.

"scroll here" is achieved by hold'n'drag

pgup behaviour allows for intermediate speed when line-by-line is too slow, while dragging is imprecise