RISC OS Open
A fast and easily customised operating system for ARM devices
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → Bounties →

Improved scroll wheel support

Subscribe to Improved scroll wheel support 98 posts, 33 voices

Posts per page:

Pages: 1 2 3 4

 
May 31, 2011 1:15pm
Avatar Trevor Johnson (329) 1652 posts

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.]

 
Jun 2, 2011 12:25pm
Avatar Andrew Hodgkinson (6) 425 posts

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.

 
Jun 2, 2011 12:36pm
Avatar Trevor Johnson (329) 1652 posts

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

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

 
Jun 2, 2011 12:53pm
Avatar Jeffrey Lee (213) 5852 posts

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)

 
Jun 2, 2011 2:10pm
Avatar Trevor Johnson (329) 1652 posts

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.

 
Jun 2, 2011 7:48pm
Avatar Dave Higton (281) 668 posts

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?

 
Jun 2, 2011 9:40pm
Avatar Jeffrey Lee (213) 5852 posts

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.

 
Jun 2, 2011 9:42pm
Avatar Andrew Hodgkinson (6) 425 posts

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 :-)

 
Mar 3, 2013 3:50pm
Avatar Matthew Phillips (473) 400 posts

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

 
Feb 21, 2017 9:43pm
Avatar Jeffrey Lee (213) 5852 posts

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

 
Feb 22, 2017 11:39am
Avatar Chris Hall (132) 2971 posts

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.

 
Feb 22, 2017 11:54am
Avatar John McCartney (426) 82 posts
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?

 
Feb 22, 2017 3:27pm
Avatar Chris Hall (132) 2971 posts
Are you using the StrongARM model?

Yes

 
Mar 8, 2017 8:21am
Avatar Matthew Phillips (473) 400 posts

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 );
    }
}

 
Mar 8, 2017 12:37pm
Avatar André Timmermans (100) 386 posts

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).

 
Mar 8, 2017 1:57pm
Avatar Jeffrey Lee (213) 5852 posts

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
 
Mar 8, 2017 7:28pm
Avatar Matthew Phillips (473) 400 posts
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.

 
Feb 25, 2020 2:36pm
Avatar Jeffrey Lee (213) 5852 posts

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?
 
Feb 25, 2020 3:55pm
Avatar Stuart Painting (5389) 419 posts

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…

 
Feb 25, 2020 3:59pm
Avatar Grahame Parish (436) 330 posts

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

 
Feb 25, 2020 5:05pm
Avatar Jeffrey Lee (213) 5852 posts

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”)

 
Feb 25, 2020 5:38pm
Avatar Chris (121) 437 posts

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?

 
Feb 25, 2020 5:48pm
Avatar John WILLIAMS (8368) 299 posts

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 …

 
Feb 25, 2020 6:11pm
Avatar Adrian Lees (1349) 122 posts

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.

 
Feb 25, 2020 6:34pm
Avatar Rick Murray (539) 10579 posts

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?

Next page

Pages: 1 2 3 4

Reply

To post replies, please first log in.

Forums → Bounties →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

Discussion of items in the bounty list.

Voices

  • Trevor Johnson (329)
  • Andrew Hodgkinson (6)
  • Jeffrey Lee (213)
  • Dave Higton (281)
  • Matthew Phillips (473)
  • Chris Hall (132)
  • John McCartney (426)
  • André Timmermans (100)
  • Stuart Painting (5389)
  • Grahame Parish (436)
  • Chris (121)
  • John WILLIAMS (8368)
  • Adrian Lees (1349)
  • Rick Murray (539)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys