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.