GPII-4384: Fix Larger mouse pointer setting in QSS

[Karadaliev]

So, by just using the mapOn/mapOff options that we already created for the other mouse settings we can just send 0.5 and 1 instead of false and true.

Everything seems to work just fine, you can test it out.

Known issues:

• The DPI scale it's still not working!!!
• When the "cursorSize" is set to 0.5 they are still visual bugs -- the cursor is black on certain positions, when you mouse over a link it shows the waiting icon and so on!

[Karadaliev]

@javihernandez @amb26 This one is fixed based on the comment in the original task. You can take a look 🛩️

[gpii-bot]

Could one of the admins verify that these changes are reasonable to test? If so, please reply with "ok to test".

[amb26]

ok to test

[gpii-bot]

CI job passed: https://ci.gpii.net/job/gpii-app-tests/1155/

[javihernandez]

Known issues:

• The DPI scale it's still not working!!!
• When the "cursorSize" is set to 0.5 they are still visual bugs -- the cursor is black on certain positions, when you mouse over a link it shows the waiting icon and so on!

Ok, I see the problem here, I'll try to explain the reason behind the "visual bugs", which apparently only affects to the "Hand" cursor, but I may be wrong.

In the QS, we tweak the generic term cursorSize to deal with the large mouse pointer. And it is mapped to a boolean setting (status) in the QS. Although neither the common term nor the application specific setting are booleans.

The windows cursor themes (or schemes in MS language) support 3 sizes: normal, large, extra large. The default is normal. Although I can see that not all the cursor sizes are consistent, this is, some of them provide normal, large and extra large while others not.

The common term has a value range from 0 to 1, and according to the ISO 24751, the recommended value (what we take as default) is 0.5.

In the case of the "Hand" cursor, we're applying the following transformation:

"Hand": {
    "transform": {
        "type": "fluid.transforms.quantize",
        "inputPath": "http://registry\\.gpii\\.net/common/cursorSize",
        "ranges": [
            {
                "upperBound": 0.333,
                "output": "%SystemRoot%\\cursors\\aero_link.cur"
            }, {
                "upperBound": 0.666,
                "output": "%SystemRoot%\\cursors\\aero_link_im.cur"
            }, {
                "output": "%SystemRoot%\\cursors\\aero_link_l.cur"
            }
        ]
    }
}

First, I'd say that this quantize transformation is not accurate because the default value in the app specific setting is the "normal", while the generic term's default value is 0.5 in a [0,1] range.
My second observation here is that aero_link_im.cur corresponds to the inverted mode of the windows default scheme, which is wrong, the three sizes of the aero_link cursors (available in the C:\Windows\Cursors folder) are aero_link (normal), aero_link_l (large), aero_link_xl (extra large).

I'm not sure what's the best way to proceed here, but for now, As a short-term solution, we can tell the QS to map off/on into 0/1, rather than 0.5/1. This way, the QS switches between windows normal size (<0.333 when transformed) and windows large size (>0.666).

As a mid/long-term, I'd say that we can revisit the windows cursor schemes and update the SR according to it, although I'm not sure this will be consistent through the different versions of Windows. Maybe is worth waiting a bit until the LSR is implemented so we can support different versions of the same solution at the same time.

@amb26, @the-t-in-rtf, what are your thoughts?

[GreggVan]

Lets go with the short term solution - if the mouse is mapped to generic

Don't hold up the 1.3.5 for this. We will just not use that button in the Case Studies.

JUST BE SURE That the CAPTURE captures the setting properly from whatever it is set in windows.

Thx
PS in the new Morphic - we are not implementing Generic and translations in the first waves - so it would be plumbed directly from the MorphicBar to the windows setting there - when we get to this button.

[amb26]

@Karadaliev - please update for conflicts now we merged "Reset to standard" fix

[gpii-bot]

CI job passed: https://ci.gpii.net/job/gpii-app-tests/1174/

[gpii-bot]

CI job failed: https://ci.gpii.net/job/gpii-app-tests/1175/

[javihernandez]

CI job failed: https://ci.gpii.net/job/gpii-app-tests/1175/

00:39:43.474:  jq: ***************
00:39:43.474:  jq: All tests concluded: 3160/3160 total passed in 69723ms - PASS
00:39:43.474:  jq: ***************
 
npm ERR! code ELIFECYCLE
npm ERR! errno 3221225477
npm ERR! [email protected] test:gpiiWindows: `set GPII_TEST_COUCH_USE_EXTERNAL=TRUE && electron testsGpiiWindows.js`
npm ERR! Exit status 3221225477
npm ERR!
npm ERR! Failed at the [email protected] test:gpiiWindows script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

is it intermittent? ok to test

[amb26]

Exit code 3221225477 is C0000005 or ACCESS_VIOLATION - we do get this from time to time (maybe 1 time in 20 or so)

[amb26]

Perhaps it will go away with the electron 7 update : P

[gpii-bot]

CI job passed: https://ci.gpii.net/job/gpii-app-tests/1176/

[GreggVan]

Thx gregg ——————————— Professor, University of Maryland, College Park Director , Trace R&D Center, UMD Co-Founder Raising the Floor. http://raisingthefloor.org And the Global Public Inclusive Infrastructure (GPII) http://GPII.net

…

On Jun 12, 2020, at 12:11 PM, Antranig Basman ***@***.***> wrote: Merged #206 <#206> into master. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#206 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXUSU7PLTRIP3GBTRDTRWJHTVANCNFSM4NSMUERA>.