bug(web): shift on- double tap behavior (cycling back to shift on), expected to go to "caps lock state",about keymanapp/keyman

MayuraVerma commented on September 18, 2024 1

there is another small issue in the same topic

Default->Single tap->shift on->Single tap->CAPS LOCK
this happens when the time gap between two single taps are short
this Behavior is as though, after the single tap, shift key was waiting for user to complete the second tap, to accept the double tap.

it maybe timing issue

this is iOS 17.2+ Sil Eurolatin KB

from keyman.

mcdurdin commented on September 18, 2024

This is a regression I believe

…

On Mon, 18 Dec 2023, 11:34 ಮಯೂರ ವರ್ಮ, ***@***.***> wrote: Describe the bug current behavior. *shift key from normal:* single tap -> shift on double tap -> caps lock *shift key from shift on:* single tap -> normal state double tap -> shift state Expected behavior. *shift key from shift on:* single tap -> normal *double tap -> caps lock* Reproduce the bug *No response* Expected behavior Expected behavior. *shift key from shift on:* single tap -> normal *double tap -> caps lock* Related issues *No response* Keyman apps - Keyman for Android - Keyman for iPhone and iPad - Keyman for Linux - Keyman for macOS - Keyman for Windows - Keyman Developer - KeymanWeb - Other - give details at bottom of form Keyman version 17.0.231 aplha Operating system *No response* Device *No response* Target application *No response* Browser *No response* Keyboard name *No response* Keyboard version *No response* Language name *No response* Additional context *No response* — Reply to this email directly, view it on GitHub <#10272>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCKHPILR7VHKUWJ5EZZDMDYJ7BVJAVCNFSM6AAAAABAY5HNOWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2DKNZRHE2DENI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

from keyman.

MayuraVerma commented on September 18, 2024

Even the single tap behavior from "Shift on" state is wrong

Single tap from "Shift on" state should release the shift state and return to normal state.

Expected behavior.
shift key from shift on:
single tap -> normal
double tap -> caps lock

from keyman.

jahorton commented on September 18, 2024

Even the single tap behavior from "Shift on" state is wrong

Single tap from "Shift on" state should release the shift state and return to normal state.

Expected behavior. shift key from shift on: single tap -> normal double tap -> caps lock

Which keyboard are you seeing this with? I'm not currently able to reproduce some of what you're talking about here.

Single tap from "Shift on" state should release the shift state and return to normal state.

... it does. Unless you're doing it quickly (within half a second or so of your last tap), in which case it thinks you're still multitapping.

Also, is this within the Keyman app, or when using it as a system-wide keyboard on your device?

Expected behavior. shift key from shift on: single tap -> normal double tap -> caps lock

Ah, okay, that is a distinct point and worth considering. It does look like that was in place during 16.0; I hadn't realized, and that would be a regression. Shouldn't be too hard to rectify with a bit of effort.

from keyman.

jahorton commented on September 18, 2024

In case someone beats me to it, or wants to:

keyman/common/web/keyboard-processor/src/keyboards/defaultLayouts.ts

Lines 529 to 545 in a84e520

    
           static dfltShiftMultitap: LayoutSubKey = { 
        
             // Needs to be something special and unique.  Typing restricts us from 
        
             // using a reserved key-id prefix, though. 
        
             id: "T_*_MT_SHIFT_TO_CAPS", 
        
             text: '*ShiftLock*', 
        
             sp: 1, 
        
             nextlayer: 'caps' 
        
           } 
        
           static dfltShiftRotaDefault: LayoutSubKey = { 
        
             // Needs to be something special and unique.  Typing restricts us from 
        
             // using a reserved key-id prefix, though. 
        
             id: "T_*_MT_SHIFT_ROTA_TO_DEFAULT", 
        
             text: '*Shift*', 
        
             sp: 1, 
        
             nextlayer: 'default' 
        
           }

Add an extra "default" key spec or two to those - those define the default multitaps for base-layer shift.

keyman/common/web/keyboard-processor/src/keyboards/activeLayout.ts

Lines 318 to 337 in a84e520

    
               // The default-layer shift key on mobile platforms should have a default multitap under 
        
               // select conditions. 
        
               // 
        
               // Note:  whether or not any other key has multitaps doesn't matter here.  Just THIS one. 
        
               if(key.id == 'K_SHIFT' && displayLayer == 'default' && layout.formFactor != 'desktop') { 
        
                 /* Extra requirements: 
        
                  * 
        
                  * 1. The SHIFT key must not specify longpress keys or have already-specified multitaps. 
        
                  * 
        
                  *    Note:  touch layouts specified on desktop layouts often do specify longpress keys; 
        
                  *    utilized modifiers aside from 'shift' become longpress keys under K_SHIFT) 
        
                  * 
        
                  * 2. There exists a specified 'caps' layer.  Otherwise, there's no destination for 
        
                  *    the default multitap. 
        
                  * 
        
                  */ 
        
                 if(!key.sk && !key.multitap && !!layout.layer.find((entry) => entry.id == 'caps')) { 
        
                   key.multitap = [Layouts.dfltShiftMultitap, Layouts.dfltShiftRotaDefault]; 
        
                 } 
        
               }

We'd want another version for the shift layer in order to set shift-layer defaults.

Those two places should be the only parts in need of an update to remedy:

Expected behavior. shift key from shift on: single tap -> normal double tap -> caps lock

It's the end of my workday, so I'll try to do this tomorrow if someone doesn't get there first.

from keyman.

MayuraVerma commented on September 18, 2024

Even the single tap behavior from "Shift on" state is wrong
Single tap from "Shift on" state should release the shift state and return to normal state.
Expected behavior. shift key from shift on: single tap -> normal double tap -> caps lock

Which keyboard are you seeing this with? I'm not currently able to reproduce some of what you're talking about here.

iOS 17.2
Sil Eurolatin

Single tap from "Shift on" state should release the shift state and return to normal state.

... it does. Unless you're doing it quickly (within half a second or so of your last tap), in which case it thinks you're still multitapping.

Also, is this within the Keyman app, or when using it as a system-wide keyboard on your device?

Both Keyman and system-wide

Expected behavior. shift key from shift on: single tap -> normal double tap -> caps lock

Ah, okay, that is a distinct point and worth considering. It does look like that was in place during 16.0; I hadn't realized, and that would be a regression. Shouldn't be too hard to rectify with a bit of effort.

from keyman.

jahorton commented on September 18, 2024

this happens when the time gap between two single taps are short

Okay, sounds like that's working fine, then. Tapping a key in between would block the behavior. We do want to allow a mild delay between taps to be handled this way for accessibility reasons.

from keyman.

MayuraVerma commented on September 18, 2024

this happens when the time gap between two single taps are short

Okay, sounds like that's working fine, then. Tapping a key in between would block the behavior. We do want to allow a mild delay between taps to be handled this way for accessibility reasons.

Shift on state; Single tap -> Normal
It’s working. As along as the time gap between first and second is long enough. But this needs to be looked into. It’s timing issue.

Shift on state; double tap -> Caps lock
This needs to be resolved. Now it’s cycling back to shift on state

from keyman.

bug(web): shift on- double tap behavior (cycling back to shift on), expected to go to "caps lock state" about keyman HOT 8 CLOSED

Comments (8)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

	static dfltShiftMultitap: LayoutSubKey = {
	// Needs to be something special and unique. Typing restricts us from
	// using a reserved key-id prefix, though.
	id: "T_*_MT_SHIFT_TO_CAPS",
	text: 'ShiftLock',
	sp: 1,
	nextlayer: 'caps'
	}

	static dfltShiftRotaDefault: LayoutSubKey = {
	// Needs to be something special and unique. Typing restricts us from
	// using a reserved key-id prefix, though.
	id: "T_*_MT_SHIFT_ROTA_TO_DEFAULT",
	text: 'Shift',
	sp: 1,
	nextlayer: 'default'
	}

	// The default-layer shift key on mobile platforms should have a default multitap under
	// select conditions.
	//
	// Note: whether or not any other key has multitaps doesn't matter here. Just THIS one.
	if(key.id == 'K_SHIFT' && displayLayer == 'default' && layout.formFactor != 'desktop') {
	/* Extra requirements:
	*
	* 1. The SHIFT key must not specify longpress keys or have already-specified multitaps.
	*
	* Note: touch layouts specified on desktop layouts often do specify longpress keys;
	* utilized modifiers aside from 'shift' become longpress keys under K_SHIFT)
	*
	* 2. There exists a specified 'caps' layer. Otherwise, there's no destination for
	* the default multitap.
	*
	*/
	if(!key.sk && !key.multitap && !!layout.layer.find((entry) => entry.id == 'caps')) {
	key.multitap = [Layouts.dfltShiftMultitap, Layouts.dfltShiftRotaDefault];
	}
	}