Improved scroll wheel support

RE: Improved scroll wheel support

We recommend a survey of different operating systems to see how much a click of a scroll wheel tends to scroll a window by.

This "An Empirical Characterisation of Electronic Document Navigation" includes some potentially useful references, although probably not the raw figures needed. An often cited work seems to be "A Simple Movement Time Model for Scrolling". (Second link courtesy of Microsoft.)

[Edit: "Comparing Speed-Dependent Automatic Zooming with Traditional Scroll, Pan, and Zoom Methods" has an interesting idea depicted in figure 1, i.e. automatic zooming out when scrolling at mid/high speed.]

It’s 2011; I think we ought to look at inertial scrolling. A click of the wheel would accelerate the window by a certain amount. The more clicks it gets while moving, the more speed it gathers.

You probably have to use Mac OS X with a Magic Mouse or Magic Trackpad, or own an iPhone or iPad, to really get this. Android copies the inertial scrolling idea too but the feel just isn’t quite “right” – still, I’m not sure it’d ever be quite “right” with a wheel either. At least using a simple physics model means you don’t have to worry too much about how to make a scroll wheel work well for both relatively short and very tall scrollable documents. Spin the wheel => picks up a great deal of speed; roll slowly => very controlled slow scrolling.

[…] inertial scrolling […] own an iPhone […]

My wife owns one but I don’t own her!

For inertial scrolling to work nicely, we’d probably want to (a) make the settings tweakable via Configure (including an option to turn it off if you don’t like it), and (b) integrate it with the mouse drivers in such a way that touchscreen-based devices can specify the scroll velocity directly instead of generating fake mouse wheel ticks. (When describing the mouse wheel rotation, “tick” is probably a better word than “click”, as “click” could refer to the use of the mouse wheel as a button)

touchscreen-based devices

I’d thought touchscreens would interpret swipes like a select-click/drag, i.e. a pan if correct tool selected or if software set up to pan rather than select text (e.g. browsers, document readers). Is there another way? Of course, touch pads often scroll documents via a vertical swipe along one edge of the pad.

touchscreen-based devices

Be very careful. The touchscreen paradigm is significantly different from the mouse paradigm.

If you touch a file icon and drag it, how does the UI know whether you want to drag the file somewhere or scroll the filer window around?

If you touch a file icon and drag it, how does the UI know whether you want to drag the file somewhere or scroll the filer window around?

Via some rules which we haven’t determined yet, because this is a discussion about scrolling, not about how to adapt RISC OS to work on touch-based devices :) All I’m really saying is that whatever this new mousewheel system is, it shouldn’t prevent alternate input devices from generating scroll events that specify exact scroll amounts. Since you can manually scroll windows by sending them “open” messages with different scroll offsets, maybe supporting different input devices isn’t such a big deal after all – although it might still be nice to be able to feed the scroll request through the same inertial scrolling code.

If you touch a file icon and drag it, how does the UI know whether you want to drag the file somewhere or scroll the filer window around?

Since redesigning RISC OS to be “tablet friendly” is an impossibly big project, the idea of having hold-delays etc. (to distinguish between an immediate swipe, or tap-hold-swipe) isn’t necessarily the way to go about this. The way you’d do it is – swipe on the scroll bar lozenge (“flick” it upwards or downwards). If your finger was hitting icons in the filer window, then that’s what it’d interact with.

Yes, this isn’t the “can swipe anywhere in a window to scroll it” model of a touchscreen or even a mouse wheel, but it’s the simplest and most reliable way to get it working in RISC OS quickly without some unrealistic huge project for redesigning the whole desktop :-)

There’s a section of Justin Fletcher’s rambles which would be useful for this: it describes the WindowScoll module implementation in RISC OS Select:

http://gerph.org/riscos/ramble/input.html#WindowScroll

I figure it’s worth digging up this thread again since there’s been some discussion about RISC OS 5’s sub-standard scroll wheel handling in the Paint bounty thread.

What are people’s opinions of the way that RISC OS Select handles things? A quick look at their docs suggests that the mouse driver delivers the events to the OS via a new EventV reason code, if the Wimp is active the WindowScroll module will then catch them and deliver scroll requests to apps as appropriate (including new Wimp messages to allow mouse wheel events to be differentiated from other scroll requests). Which is surely a far better way of doing things than how RISC OS 5 currently does it.

http://riscos.com/support/developers/riscos6/input/pointerdevices.html (describes scrollwheels as an “alternate positioning device”)
http://riscos.com/support/developers/riscos6/input/windowscroll.html

Scroll wheel movement seems to work well on my ARMX6 under RISC OS 5. All I really want to do is to be able to use the scroll wheel to scroll up and down. It doesn’t work in VRPC Adjust (RISC OS 4.39) which is my version of Select.

Scroll wheel movement seems to work well on my ARMX6 under RISC OS 5. All I really want to do is to be able to use the scroll wheel to scroll up and down. It doesn’t work in VRPC Adjust (RISC OS 4.39) which is my version of Select.

I use the ARM7500 model and the scroll wheel works very well. Are you using the StrongARM model?

Are you using the StrongARM model?

Yes

I think Jeffrey isn’t so much asking about whether the user experience is good, but whether the API is good. The RISC OS 5 way of doing things presents considerable difficulties if you want to interpret scroll wheel events yourself. I think that unless you have HID running on RISC OS 5 then the scroll wheel only generates Scroll Request (Wimp poll code 10) and many windows do not listen for these. HID converts these to Open Window events, but not all users have HID running.

On RISC OS Select the API is much more sophisticated.

When we were first developing RiscOSM we had problems because we wanted the scroll wheel over the map to zoom in and out (change the scale of the map) like it does with web-based mapping on Windows etc. Support on RISC OS Select was simple. Support on RISC OS 5 required a huge chunk of code to detect the multiple Scroll Request events and act appropriately. I’ll paste it here below so you can see the contortions required. It won’t make complete sense because it’s part of a bigger library used for RiscOSM, Impact and Wrangler, but you’ll get the idea.

I would support RISC OS 5 behaving like Select, though to add plain up and down scrolling to existing applications that have not been adapted will still require some sort of faking. It would be awkward if RISC OS 5 introduced a new API that was not compatible with Select.

static void ScrollRequest( void )
{
    static int wind = 0, count = 0, last = 0;
    static int x=-100, y=-100, transmit = FALSE;
    int *event = W_WimpEvent();
    int scrollWheel = FALSE, faked = FALSE;
    int xdir, ydir;
    int block[5];

    if ( event[8] > 3 || event[8] < -3 || event[9] > 3 || event[9] < -3 )
        scrollWheel = TRUE;

    /* Check if it is an unknown scroll type and ignore if so. */
    if ( scrollWheel && (event[8] & 3 || event[9] & 3) )  return;

    W_WimpGetPointerInfo( block );

    /* If it's not an auto-scroll or already identified as a scroll wheel
       event, see if the mouse is over scrollbars or nudge icons. */
    if ( !scrollWheel && event[8]!=-3 && event[8]!=3 && event[9]!=-3 && event[9]!=3 )
    {
        if ( block[3]==event[0] && ( block[4]>-6 || block[4]<-12 || block[4]==-9 ) )
        {
            /* If the mouse is not over the scrollbars, fake a scroll wheel
               event, compatible with RO Select WindowScroll module. */
            scrollWheel = TRUE;
            faked = TRUE;
        }
    }

    /* Could this be one of a series of repeated Scroll Requests generated
       by !HID or RISC OS 5 ?  See if the window matches.  */
    if ( faked && count && wind==event[0] && Time() - last < 10 && x==block[0] && y==block[1] )
    {
        count--;

        if ( transmit )  WIN_ProcessScrollRequest( event );

        return;
    }

    /* If we need to fake a scroll wheel event, set up the event block. */
    if ( faked )
    {
        xdir = event[8];
        ydir = event[9];

        if ( event[8] )  event[8] = (xdir<0) ? -4 : 4;
        if ( event[9] )  event[9] = (ydir<0) ? -4 : 4;
        event[10] = block[4];

        /* Note that icons are only meant to receive scroll requests if
           the validation string Y value includes S.  Otherwise the icon
           number should be set to -1.  The window library routines do
           different things with the icon numbers anyway.  In this faked
           message system we would see two differences between RO 5 and
           RO Select:

         * If an icon included S in validation Y, on RO Select it would
           presumably receive the messages even if the window flags did
           not ask for Scroll Request poll codes.  We just need to make
           sure we always ask for them: our fallback handling code in
           the window library means this is not an issue for handling
           ordinary scroll requests on windows.

         * If an icon wanted scroll requests but overlapped with a higher
           numbered icon not receiving such requests, then on RO Select
           we would either get no Scroll Request or one relating to the
           whole window.  On RO 5, however, we fake one for the higher
           numbered icon and the windowing routines ensure it is passed
           to the lower numbered icons handlers also.  Icons arranged
           in this way are mainly found on Impact record cards: they can
           be avoided in templates designed by the programmer.

         */

        count = 4;  /* swallow up to four following scroll requests */
        x = block[0];
        y = block[1];
        last = Time();
        wind = event[0];
        transmit = FALSE;
    }

    /* Simplify handlers by ensuring icon number is always set. */
    if ( !scrollWheel )  event[10] = -1;

    /* Process the event.  If unclaimed, and we were faking, resend as an
       ordinary event. */
    if ( !WIN_ProcessScrollRequest( event ) && faked )
    {
        /* Restore the original event block. */
        event[8] = xdir;
        event[9] = ydir;

        /* Note that the following messages are not to be suppressed. */
        transmit = TRUE;

        WIN_ProcessScrollRequest( event );
    }
}

Well, having the USB driver or HID handling scrolling in windows is certainly not very logical.

Concerning the ROL API, I have used it in a few processes and the issues I had with it are:
- extended Wimp_ScrollRequest API is ok unless you want to use the wheel info for special purposes (like altering the volume in a media player) in a window which has no scroll bars because IIRC in that case you receive no scroll request.
- SWI OS_Pointer,2 which I tried for non-multitasking applications crashed on RISC OS 4 instead of returning an error (I can’t remember how OS 5 behaved).

If an icon wanted scroll requests but overlapped with a higher numbered icon not receiving such requests, then on RO Select we would either get no Scroll Request or one relating to the whole window. On RO 5, however, we fake one for the higher numbered icon and the windowing routines ensure it is passed to the lower numbered icons handlers also. Icons arranged in this way are mainly found on Impact record cards: they can be avoided in templates designed by the programmer.

Do you have any preference for how we should deal with this kind of situation in RISC OS 5?

The two cases that would make the most sense to me are:

• Scan the icons in reverse order (highest number to lowest) until we find one under the pointer. If it has extended scroll requests enabled then send the event to it. So essentially implement the logic you’re already using for RISC OS 5.
• Scan all the icons (forward? reverse?) and send the request to the first one we find which is under the pointer and supports extended scroll requests

Worst-case the OS will always have to scan through all of the icons in a window (e.g. if the pointer isn’t over any icon), so there’s no real difference in performance between the two approaches. It’s just a question of which approach people think would make the most sense (and maybe which one will lead to the least compatibility issues with RISC OS Select – although I guess it should be possible to softload the RISC OS 5 version of the WimpScroll module on Select if apps start to become reliant on the RISC OS 5 behaviour)

- extended Wimp_ScrollRequest API is ok unless you want to use the wheel info for special purposes (like altering the volume in a media player) in a window which has no scroll bars because IIRC in that case you receive no scroll request.

My reading of ROL’s spec suggests that it operates in the following manner:

1. Determine which window to start the search from (Pointer/Focus/FocusOrPointer/FavourHigher setting)
2. If the window is a pane, does not have scroll bars, and does not have the “extended scroll” flag set, try the window behind the pane
3. Repeat step 2 until a suitable window is found
4. If the pointer is over an icon which accepts extended scroll requests (new “YS” validation command), send an extended scroll request to that icon
5. Otherwise, if the window accepts extended scroll requests, send an extended scroll request to the window
6. Otherwise, if the window has scroll bars, generate a sequence of regular scroll requests

If an icon wanted scroll requests but overlapped with a higher numbered icon not receiving such requests, then on RO Select we would either get no Scroll Request or one relating to the whole window. On RO 5, however, we fake one for the higher numbered icon and the windowing routines ensure it is passed to the lower numbered icons handlers also. Icons arranged in this way are mainly found on Impact record cards: they can be avoided in templates designed by the programmer.

Do you have any preference for how we should deal with this kind of situation in RISC OS 5?

Sorry, that code comment is perhaps a bit unhelpful. It refers to the Impact library’s method for handling the database record cards designed by the users and is not relevant to how the Wimp generally operates, as far as I understand things!

Because users of Impact place writable icons for entering data, radio buttons, labels etc. on the card, the software has to cope with imperfect placement by the users and the bounding boxes of icons (particularly labels) overlapping each other. The Wimp picks a single icon that the mouse is over — the one with the highest number, I suspect from my comment about Select — and the mouse click event or scroll request will refer to that icon.

Impact’s event library routines (also used by RiscOSM and a few of our other applications) will work through all the icons whose bounding boxes overlap the stated position, and call the appropriate event handlers until it finds one that claims the event.

So at present, on RISC OS 5 we are able to receive the repeated scroll requests and fake a scroll wheel event for each of the overlapping icons. On RISC OS Select we may not get the event if the top-most icon isn’t wanting them.

I would be happy if RISC OS 5 ended up behaving the same way as RISC OS Select in this situation. In actual fact, Impact does not register to handle these scroll request events for any icons, so it is immaterial. RiscOSM does not have user-designed windows and so there are no icons overlapping in this way.

The note was therefore a detailed warning to me about what behaviour to expect in these edge cases, justifying why none of them were actually a concern.

In order to provide an implementation that’s compatible with RISC OS Select, I’m proposing:

• Removing the code from USBDriver which sends window scroll requests. Instead, USBDriver will only issue the (RISC OS 5 specific) PointerV 9 call (I think under Select only Pointer V 4 allows drivers to report scroll wheel position, but PointerV 4 isn’t used at all by RISC OS 5)
• The kernel will gain code for tracking the scroll wheel position and any extra mouse buttons (under Select this is all handled by the OSPointer module)
  • The kernel will listen for PointerV 9 and update its copy of the scroll wheel position and extra mouse buttons
  • OS_Pointer 2 will be implemented for returning the current scroll wheel position (same as Select). This goes against the older NCOS usage of the reason code (for detecting pointer presence), but that’s probably acceptable
    • Wrapping: The RISC OS 6 PRM text says “The device position is unbounded and thus may wrap when the limits of the 32bit representation are reached. Should the device position wrap past a limit, it will be reset to zero. Thus, should the position exceed either &7FFFFFFF or -&80000000 it will be reset.”. Resetting to zero sounds a bit counter-intuitive – can anyone confirm if that’s what OSPointer actually does?
  • Any changes in scroll wheel position will be broadcast by EventV 21,4. This will be issued from a callback (unless anyone can think of a good reason why it should be issued directly from PointerV? bearing in mind the PointerV call will likely be from within the mouse driver’s interrupt handler).
    • “If clients wish to cause the scroll event to be ignored they should claim the event.” – Does claiming the event just stop it propagating to other EventV listeners, or does it also stop the OS_Pointer 2 values from updating? I guess the latter would make the most sense.
  • The state of extra mouse buttons will be returned via OS_Mouse (as per Select)
• A WindowScroll module will be added to the ROM, mimicking the behaviour and functionality of ROL’s version of the module
  • Scroll events will be detected via EventV 21,4
  • ROL’s docs don’t mention where settings are saved. Since we’re including the module in ROM, I’m proposing that the settings will be saved in CMOS RAM. I suspect a single byte will be sufficient – 2 bits for scroll type, 1 bit for line scroll flag, and 5 bits for 32 levels of scroll speed.
• There’ll be an updated Configure plugin. Probably the Windows plugin, since the settings only apply to Wimp usage?

There’ll be an updated Configure plugin.

Could we have a setting for “direction of scroll” as well? Or would that be better placed on Mouse configuration? Having the scroll wheel operate the opposite way to most other devices on the market is a bit awkward for me, and my chances of getting them to change are slim to none…

Would Alt-scroll be a useful addition to allow scrolling through the active windows (back and forward)?

Could we have a setting for “direction of scroll” as well? Or would that be better placed on Mouse configuration?

I’d imagine that would be a mouse configuration setting (i.e. affecting all scroll wheel APIs), rather than a Wimp-specific setting.

I’m assuming it’s Apple mice which you’re having trouble with, since macOS is the only platform I know of which uses an inverted scroll direction. So my question is, is it the mouse which is generating the inverted data, or is it the OS? (I know there’s a setting within macOS for the scroll direction, but I haven’t tried a mac mouse on a non-mac machine, or vice-versa, so I don’t know what values the hardware is reporting)

Would Alt-scroll be a useful addition to allow scrolling through the active windows (back and forward)?

That’s one advantage of having the Wimp scroll wheel handling in a single-purpose module – people will be able to easily suppress the default behaviour and use a third-party module which offers different functionality.

(Or in other words, “that’s a nice idea, but I probably won’t find the time to implement it”)

There’ll be an updated Configure plugin. Probably the Windows plugin, since the settings only apply to Wimp usage?

Out of interest, what needs to go in the Configure plugin? The Windows plugin is already pretty a big window (and includes the Iconbar settings, which has always struck me as odd – the Iconbar is only a ‘window’ from a programmer’s point of view). Even if the new settings only make sense in the Wimp context, are these not better placed in the Mouse plugin?

The Windows plugin is already pretty a big window (and includes the Iconbar settings, which has always struck me as odd

In which case could the iconbar usefully have its own plugin, releasing space, if the new settings really belong there?

Just an alternative option …

Not immediately connected with scroll wheel support, but related… if the Mouse plugin and handling is changed can we please finally have support for exchanging the primary and secondary mouse buttons (Select|Adjust) for those who – like me – often use the mouse left-handed.

Also, and perhaps someone who was present would care to comment/clarify, I overheard part of a discussion at the South West Show about having a configuration switch to exchange Menu and Adjust such that those new to the platform have the more familiar ‘right button = menu’ functionality.

I can’t say I’m a fan of aping other systems, especially when I regard their approach as inferior, but alas people are creatures of habit and often struggle to accept the unfamiliar.

I’m proposing:

Will software that sees the window scroll events (currently faked up by the USB code (eek!)) still work?

This goes against the older NCOS usage of the reason code

Hands up who develops for NCOS?

<looks around>

That’s what I thought. ;-)

[the last time I saw NCOS, it was inside a Bush Box]

Resetting to zero sounds a bit counter-intuitive – can anyone confirm if that’s what OSPointer actually does?

If you think about it, going from +veBIG wrapping to -veBIG (or vice versa) would basically be the exact opposite scroll position, which could be disturbing to see; but if one is right at the boundary then gently scrolling up and down might cause the UI to freak out if the system is seeing alternating between +most and -most. It’s likely that resetting to zero is to rebase the pointer so that it’ll be a small glitch, not a big one.

That said, it sounds like a lurking gotcha. How does the current impementation work, and might it not make sense to quietly reset it to zero (and teach OS/Wimp that zero means “leave it where it is”) rather than continually adding/subtracting until something eventually wraps?

unless anyone can think of a good reason why it should be issued directly from PointerV

How does the Wimp handle mouse movements? Does it look at PointerV? If so, it might make sense to include everything together.
After all, there’s no reason why a client module can’t look at PointerV and issue its own callback. There’s enough of RISC OS back end stuff running in unsafe contexts that issuing callbacks is not an unusual or unexpected requirement.

I’m proposing that the settings will be saved in CMOS RAM.

Why CMOS?
Why not set a “useful default” and then have a command to change this if the user prefers, akin to WimpVisualFlags.

Would Alt-scroll be a useful addition to allow scrolling through the active windows (back and forward)?

If reaching for the keyboard, what’s wrong with using CoolSwitch to mimic Windows Alt-Tab behaviour?

since macOS is the only platform I know of which uses an inverted scroll direction

Think different. ;-)

are these not better placed in the Mouse plugin?

Yes. It’s where I’d look as the scrollwheel is a part of the mouse…

which has always struck me as odd – the Iconbar is only a ‘window’ from a programmer’s point of view

Probably a semi-logical place it could be shoved without making a new plugin. The “Open submenus automatically” stuff doesn’t really belong there either. Perhaps “Windows” should be renamed “Desktop UI” and given scroll bars so these things can fit into it?