Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • D Dual Function Keys
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4
    • Issues 4
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • interception
  • linux
  • plugins
  • Dual Function Keys
  • Issues
  • #6
Closed
Open
Created Jul 08, 2020 by D. Debnath@keyb0ardninja

Home row keys as modifiers is unusable with current implementation

I was trying the dfk.home-row-modifiers.yaml given in the examples. This is an excellent idea. But, I found it unusable. This is a proposal on how to make it usable.

Example: Holding KEY_A for LEFT_SHIFT

Press and release a within TAP_MILLIS (default 200ms) for a.

If press exceeds TAP_MILLIS, we get LS.

                <---------200ms--------->     <---------200ms--------->
keyboard:       a↓      a↑                    a↓                             a↑
computer sees:            a↓ a↑                                        LS↓     LS↑

If other keys are pressed in between press and release, how to handle it:

Typing the string as:

                <---------200ms--------->
                          <---------200ms--------->
keyboard:       a↓        s↓     a↑         s↑
computer sees:                     a↓a↑       s↓s↑

This is extremely important because the "smooth" touch typing experience comes from pressing the next key before releasing the current key. This gives that "gliding" motion from one key to the next. The current implementation is unusable for a touch typist. The current implementation will just ignore the inbetween keypress, as it is mentioned in the README:

Press or release another key during the TAP_MILLIS window and the tap will not occur.

This is especially useful for modifiers, for instance a quick ctrl-C. In this example we press the a key during the window.

The problem is that if you're using the homerow keys as modifiers, it is impossible to slow yourself down during typing as it will break your flow, but it is not a big problem to slow yourself down when hitting a shortcut, because you're most likely not going to press a series of shortcut after shortcut with a flow.

Typing Shift + s:

                <---------200ms--------->
                             <---------200ms--------->
keyboard:       a↓           s↓              s↑    (---a↑----)
computer sees:                           LS↓  s↓s↑ (---LS↑---)

(---a↑----) is used to mean that the key a can be released anywhere in that time range.

Typing a, quickly followed by LEFT_CTRL:

                <---------200ms--------->
                             <---------200ms--------->
keyboard:       a↓           s↓    a↑                      s↑
computer sees:                       a↓a↑             LC↓    LC↑
Assignee
Assign to
Time tracking