Closed 1j01 closed 4 months ago
so I'm not making this a todo list for this issue but I wanted to gather all the "toggling" related concerns in one place, because it's pretty complicated already in the multi-process architecture, and I want to add more features/cases, hopefully without blowing my complexity budget on "toggling"
Some of these are implemented and some are not:
Event/Condition | Action |
---|---|
on first time running | disable dwell clicking |
on startup | disable dwell clicking for a period if configured to start automatically, otherwise just disable |
after click or drag release (from dwell or otherwise) | disable dwell clicking for a period |
after a dwell click is canceled due to an element popping up in front, or occluding the center of the hovered element | disable dwell clicking for a period |
after page becomes focused after being unfocused | disable dwell clicking for a period |
if head not detected | disable dwell clicking for a period |
if head detected but not large/close enough | disable dwell clicking for a period |
pause button | toggle dwell clicking |
global keyboard shortcut (F9) | toggle dwell clicking |
local keyboard shortcut (F9) | toggle dwell clicking |
if app window is closed | disable dwell clicking (failsafe) |
if mouse moved manually | disable dwell clicking for a period |
if mouse clicked manually | disable dwell clicking for a period |
if paused in the debugger | disable dwell clicking (may need an IPC heartbeat mechanism) |
Some more scattered notes:
It shouldn't unpause if another condition's period is still in effect. I could use a queue of disabling effect timers, but what I actually already did which is simpler (and which I forgot about) is:
const deactivate_for_at_least = (timespan) => {
inactive_until_time = Math.max(inactive_until_time, Date.now() + timespan);
};
(Hm, I should probably use performance.now()
instead, to ignore clock changes... Done. Don't need weird bugs from clocks going back in time.)
I'd also like to show a countdown to re-enabling, in the screen overlay, as well as icons showing why it's paused: https://github.com/1j01/tracky-mouse/issues/20
A queue might still help with showing a HUD message of why it's paused. Or it might not!
I'm probably going to want to establish some general sort of state replication for things like the settings and toggle state(s). But it won't help with everything.
I'm still not sure when all it should toggle just dwell clicking vs. all control vs. just other control (mouse movement, currently), and how that should look within the UI.
I added a button to the UI that does the same thing as the global shortcut (F9): toggles head tracking cursor movement, in both desktop and web library contexts, and, in the desktop app, also dwell clicking, but not in the web library.
I might just call this done for now.
There is so far a global shortcut, F9, which toggles both features on/off at once in the desktop app, with an overlay on the screen to tell you about the shortcut and the current state. The same shortcut is listened for in the web library, although without an overlay message, and it doesn't toggle the dwell clicker. It toggles the dwell clicker in the Electron app because I have it set up to toggle the dwell clicker when the head tracker is toggled.
There should be a way to toggle each feature on/off, visible in the UI. Perhaps just two checkboxes, or perhaps big toggle buttons in order to be more prominent.