Improved scroll wheel support

PipeDream ought to be responsive to extended scroll requests – scroll by five lines is what the code says!

Yep, that’s working with the new code, thanks. It looks like NetSurf supports them too (should have thought of checking that earlier!)

I don’t suppose it might be possible to scroll menus under the pointer?

Not at the moment – I’ll see if I can get it working.

the plan is to do something about ticket #478 in time for RISC OS 5.28

Great!

Before I spend too long hunting around myself, does anyone know of any (free) software which supports the extended scroll requests? Preferably an example of window scrolling and icon scrolling.

RiscOSM has a free demo which is fully functional but limited to showing maps of the Isle of Man, North Wales and part of the Netherlands. If you go to our website and download the demo and Isle of Man data you should be able to test. As far as we can remember, there is only scroll mouse support over the map window to zoom in/out in scale. No scroll-wheel over any of the icons.

I’m not sure whether RiscOSM is a good example for testing with, as it does its best to respond to HID and the RISC OS 5 limited scroll wheel support too (see the code further up this topic), so you may find it hard to test if your new code is having the right effect. If you’d like we could probably send you a version that only supports the extended scroll requests and not the other methods. Get in touch via the contact form

I’ve been trying out the new WindowScroll module which does what it says on the tin.
Anything that already had scroll wheel support still scrolls at the old fixed slow scroll rate. e.g. Filer windows and Zap.

Anything that already had scroll wheel support still scrolls at the old fixed slow scroll rate

Probably depends upon whether they support the methods used by ScrollWheel or if it reverts to the older way of either sending scroll requests or fiddling the window position and getting the app to reopen it.

I suspect that you’d need ScrollWheel aware apps to work properly.

Anything that already had scroll wheel support still scrolls at the old fixed slow scroll rate. e.g. Filer windows and Zap.

Do you have the updated USBDriver ?

I didn’t. But I do now. No more slow scrolling. Thanks.

Following on from some of the things mentioned in this thread, I’m wondering how we can extend the extended scroll requests so that the behaviour is more consistent between different apps. Some of the issues we’re facing are:

• Extended scroll requests indicate the scroll distance by stating the number of wheel “ticks”, but there’s no standard mapping from ticks to OS units
  • E.g. PipeDream will scroll 5 spreadsheet rows per tick, while NetSurf will scroll by half the window height per tick
• Extended scroll requests are intended to be used for more than just scrolling windows; e.g. they can be used for scrolling icons, or scrolling non-Wimp UI elements (like nested frames in NetSurf, or they could be used for zooming. This means that if a scroll event generator tries to determine how far a window has scrolled by reading back its new scroll offsets, there’s a reasonable chance that it’ll get an answer of zero (e.g. icon or non-Wimp UI being scrolled), or a completely misleading result (e.g. scroll offsets changing as a side-effect of a window being zoomed). So software which tries to scroll a window a specific distance by calculating the “ticks to OS units” ratio that an app is using is either going to be unable to calculate the value (measured distance of zero) or get a completely incorrect value and run the risk of “scrolling” way too far (the “scroll offset changed as a side-effect of zooming” case).
  • Normal scroll events have the same problem of there being no fixed mapping between “ticks” and OS units, but because those events should only be used for scrolling, it is possible for software to fairly reliably measure the scroll distance and calculate a suitable multiplier, like WindowScroll now does
• Because extended scroll requests are intended to be used for the scroll wheel, it’d be wrong for scroll event generators to work around the above problem by sending normal scroll events or OpenWindow events instead
• The only way an app can control whether extended scrolls are used is to enable/disable its advertising of support for the feature. So apps which want to switch between two different behaviours can’t easily make it so that extended events are only used when control is held – they’d have to constantly monitor the state of the control key and update their window/icon definitions each time the state changes.
  • E.g. Paint switches between scrolling & zooming depending on whether control is held
  • Edit’s scrolling logic is having problems too – it assumes that any OpenWindow request which only changes the scroll offsets is the result of the user clicking/dragging the scroll bar, and in response it activates some “thumbing” logic where instead of immediately jumping to the new scroll position it will smoothly scroll towards that position (and will immediately stop once the user releases the mouse buttons). This is intended to make it easier to navigate large documents (you’ll be able to see the intervening pages of text that would have normally been skipped completely), but it’ll only work properly if Edit can reliably determine that the OpenWindow request is because of interaction with the scroll bars. Scroll wheel events throw a spanner in the works, because if WindowScroll is sending OpenWindow requests then there’s no way for Edit to work out whether it’s a wheel scroll event or a scroll bar interaction (neither the mouse position nor button state can reliably be used to differentiate between the two). Changing Edit to support extended scroll requests would solve this, but then leaves us back with the problem that WindowScroll won’t be able to apply the user’s speed/scale factor.
• Because each tick is likely to map to motion of more than 1 pixel, it limits the ability to scroll a precise distance, or to perform smooth scrolling

To solve the above problems, I think the best solution is probably going to be to add a new way of handling scroll wheel events, based on Wimp user messages. I.e. the scroll event generator will send a recorded user message to the target task, letting it know the details of the scroll operation (e.g. target window & icon, and the X & Y scroll deltas, in both “ticks” and OS units, as appropriate). The receiving task is then expected to scroll appropriately. If no reply is received, the generator can assume the new protocol isn’t supported, and fall back to the older method(s).

However we should probably aim to make this new solution a bit more comprehensive than just “extended scroll requests with a couple of extra fields” – e.g. maybe it should be a “start scrolling → continue scrolling → stop scrolling” sequence to allow programs to implement their own smooth scrolling logic. And it should probably include some screen coordinates, so that the target task can reliably determine what bit of UI should be scrolled (could be useful for alternate input devices like touch screens, and it’ll avoid the problem that I’ve seen with some macOS apps, where the inertial scrolling will suddenly start scrolling a different UI element because you moved your mouse while the inertia is still running out). And on the subject of touch screens/alternate input devices, maybe it should also cater for zoom operations?

Unfortunately that’s now sounding like an API that’ll take a lot of work to design, so unless someone has an existing design hidden away in a notebook somewhere I suspect the fixes I’ll be making for RISC OS 5.28 will just involve switching Edit and Paint over to using the current extended scroll request system, and forget about trying to make them react to user’s speed setting.

There was also a much simpler alternative I was thinking of, where a system variable (Wimp$WheelSpeed?) could be used to store the speed scale factor, but since that only solves some of the issues we’re facing I’m not sure if I like it.

I’m wondering how we can extend the extended scroll requests so that the behaviour is more consistent between different apps.

An observation from having used it, rather than anything substantive to contribute: there does seem to be a differing “gain” between applications, which wasn’t there previously when USBDriver injected the messages directly.

I think you already captured the main ones I was thinking of, but say I set the speed in the configure plugin to something reasonably high in order to navigate in StrongEd without wearing my finger out, if I navigate the same document in Edit there’s not much movement at all.

So, if an application hasn’t actively opted in to the extended requests (via window flaggage and/or Ys validation), does it make sense to have WindowScroll just do whatever USBDriver did before? That might mean ignoring the speed setting, maybe that’ll serve as impetus for more apps to move over to extended requests over the next 10-15 years…

From a non-technical perspective.

Scrolling performed as expected and the applications I used daily worked without issue, even though I didn’t update !Configure…

My only observation was that when moving between some builds -forwards→ the mouse or keyboard stopped working, which was solved when it was discovered that a reinit of the usb module worked a treat!

What does vncserver do?

I note that setting wimpscroll -Speed 0 stops all scrolling from the desktop but in vncserver I can still scroll. However PDF doesn’t scroll.

Setting -Speed 1 doesn’t change the scrolling rate in vncserver but it does make PDF scroll at a reasonable pace. Having the same file open in edit and stronged with the same window size shows stronged scrolls twice as fast as edit at the desktop. With vnc scrolling is in edit and stronged is fast – I can scroll 8 lines just rocking my fingers. Edit exhibits a momentum effect and it appears I can travel further than stronged when moving my fingers from top to bottom

I set the speed in the configure plugin to something reasonably high in order to navigate in StrongEd without wearing my finger out, if I navigate the same document in Edit there’s not much movement at all.

That’s because Edit is a special snowflake which:

1. Doesn’t work very well with the OpenWindow style of scrolling because it confuses the OpenWindow request for a drag on the scroll bar, which causes it to (briefly) enter the “thumbing” mode and ignore the scroll distance that WindowScroll has asked for
2. Doesn’t work very well with normal scroll requests because Edit scrolls its window by adjusting the min/max workspace extents, not by adjusting the scroll offsets – which defeats WindowScroll’s current logic for trying to measure the “ticks to OS units” ratio (could be solved by making WindowScroll smarter, but we’d still be left with the OpenWindow mode not working, which won’t help people who don’t enable the “line scroll” / “line multiple” option)

does it make sense to have WindowScroll just do whatever USBDriver did before?

USBDriver only sent normal scroll requests (making it impossible to scroll windows which don’t support them, like the task manager), and would send five of them for every wheel tick (resulting in shenanigans like this and this)

What does vncserver do?

“USBDriver lite”. It sends normal scroll requests, but only 1 at a time. There’ll be a new version out soon which will prefer to send the events to WindowScroll if it’s active.

With vnc scrolling is in edit and stronged is fast – I can scroll 8 lines just rocking my fingers

There’s probably some variance due to different OS’s & mice scaling the wheel events differently.

I set the speed in the configure plugin to something reasonably high in order to navigate in StrongEd without wearing my finger out, if I navigate the same document in Edit there’s not much movement at all.

That’s because Edit is a special snowflake which:

I recall reading the scrolling logic in Edit a few years ago and thinking “huh, that’s cute, I wonder why nobody else ever picked up the idea of endlessly resizing the scrollbar depending on how much of the file was on screen”. It doesn’t seem to help that much for uniformly dense files since beyond a few hundred lines the scrollbar gets so small the text whizzes past whatever you do.

does it make sense to have WindowScroll just do whatever USBDriver did before?

USBDriver only sent normal scroll requests (making it impossible to scroll windows which don’t support them, like the task manager), and would send five of them for every wheel tick (resulting in shenanigans like this and this)

Ah, but you’ve trimmed the important qualifier: “if an application hasn’t actively opted in to the extended requests (via window flaggage and/or Ys validation)”. In other words, only use the USBDriver 5-at-a-time weirdness if not opted in. It’s kind of a variant on a theme of the recorded user message bounce idea. There’s a gaping hole though if they do process scroll requests but haven’t used a window block flag or Ys, hmm.

USBDriver 5-at-a-time weirdness

Yes, that was kind of my point ;-) USBDriver’s scroll method was weird, so it doesn’t make sense for it to be used as the default behaviour. Ordinary scrollable windows should automatically work sensibly with the scroll wheel without the author needing to add extra code.

That’s because Edit is a special snowflake

I’d always been confused by the scrollbar handling in Edit, but I’d never used it for long enough to work out what it was up to.

The author of edit needs a medal for ingenuity. In my attempts to rationalise the code I got the feeling it was originally designed not to hold all the file in memory at once because of its chunky buffer nature and that that it gives up looking backwards for paragraph starts if its too far away – which is the cause of the bug where the text goes all wonky.

Just thought I’d vote for the new mousewheel method. I like it, it’s not perfect but for me it’s better than before. It’s nice that windows that didn’t scroll with the mousewheel now scroll.

originally designed not to hold all the file in memory at once

I know that it is a feature of the unix world VIM to partially load a file. there are probably others. It could still have relevance today for examining the header of video or other large files. I guess editing/saving would be a complication or impossible without loading the whole file.

If NetSurf’s scrollwheel handling is a problem, please explain what it should be so it can get fixed.

If NetSurf’s scrollwheel handling is a problem, please explain what it should be so it can get fixed.

It’s not a problem; I was just using it as an example of where software had to work around the behaviour of the old implementation.

It’s not a problem; I was just using it as an example of where software had to work around the behaviour of the old implementation.

Okay. Half the height of the window sounded like a big jump for a single click.

If we can tell Michael Drake how Netsurf should behave, he’s a particularly well-placed person to implement it.

There is a question of how NS should cope with versions of RO before and after the change to the scroll wheel support.

Okay. Half the height of the window sounded like a big jump for a single click.

Yes, it’s probably a bit on the big side. But I’d assumed it was a conscious design decision, rather than a bug (e.g. I’d expect to see the same behaviour on RISC OS Select)

However, some archaeology leads me to this commit where support for extended scroll requests was first introduced:

http://git.netsurf-browser.org/netsurf.git/commit/?id=7fbb51d79903dffc26ca8f295cc770f83b6ad7ff

The code is broadly the same as it is now, but there’s one key difference which suggests that the current behaviour might actually be a bug in NetSurf: some code has crept in which multiplies the scroll delta by two.

Old code – page up is +y, extended scroll is (y * (scroll->ymin>>2)) >> 2 (one quarter window height per wheel tick)

New code – page up is SCROLL_PAGE_UP, which gets mapped to +visible_y just below. Extended scroll uses step_y = -((visible_y * (scroll_y>>2)) >> 2), but then further below it gets applied as state.yscroll -= 2 * step_y, so now it’s scrolling in half-window chunks instead of quarter-window chunks.

However I haven’t tracked down when the *2 was introduced, so maybe that was a deliberate change.

If we can tell Michael Drake how Netsurf should behave, he’s a particularly well-placed person to implement it.

There’s a distinction between how software should behave, and how that behaviour should be implemented. I can provide help with the second, but the first is more of a question for a UI designer (or the Style Guide, but a quick search through the ROOL version doesn’t yield anything relating to scroll wheel interaction).

There is a question of how NS should cope with versions of RO before and after the change to the scroll wheel support.

In order to cope with different OS versions, I don’t think any change is needed. Old versions of RISC OS 5 will have delivered 5x normal scroll requests. New versions will be delivering extended scroll requests (in a manner which should match the behaviour of RISC OS Select). The code in NetSurf which deals with the 5x scroll requests from old RISC OS 5 is on a code path that won’t be hit if it’s an extended scroll request which is received.

I just did a bit of testing in Windows and it’s inconsistent there too. In Notepad and Visual Studio, one click on the arrow scrolls down one line, but one click of the wheel scrolls down three. In Edge, the wheel scrolls eight lines but the arrow only six.

[Post originally had some other stuff but I removed it after managing to undermine my own argument!]

Another thread mentions that DigitalCD makes use extended scroll requests to control sliders with the wheel. This reminds me that this behaviour was copied from ROL’s work on the Toolbox to make use of the wheel in the colour picker, slider gadgets and maybe other parts of the Toolbox.
It could be worth to check the OS 6 docs and replicate some of that work.

Where should we be with !Edit scrolling !Edit scrolling?

*wimpscroll
Current settings:
Type: Pointer
Linescroll: On
Speed: 12

With OS 5.27 (07 May 2020) !Edit scrolls one line at a time, but with OS 5.27 (18 May 2020) it scrolls 4 lines at a time and does not follow scroll settings. The difference being this.

Also noted is that !Store’s Catalogue window does not scroll.