Ongoing fixes #874
Ongoing fixes #874
Conversation
There was a problem hiding this comment.
@JuliusSweetland This looks like a bug but wasn't causing a problem, could you please pass your eyes over it too
There was a problem hiding this comment.
Regarding key selection while point selection is underway, how does this behave for you? I did the exact same thing, and when I tested I was able to select keys during point selection, but the selected keys never seemed to be acted on. This lead me to believe we may need to implement a queue so newly selected actions fire after the point selection action completes.
|
force-push to fix last commit and remove WIP re point selection @AdamRoden I'd only just got that far as a first step, still investigating... |
@kmcnaught I can't see exactly what you are referring to, but all commits look good to me. Thanks. |
|
@JuliusSweetland feel free to have a play with left click locking feature here. I've braindumped my current thoughts re: UX / next steps over at #744 |
|
I have force pushed with squashed commits and an update to fix unit tests that broke when selection event API changed |
This reverts commit 25f5d16.
The official release has a bug with the "Alt" key, which was fixed but not released so I've rolled my own release and changed all the Optikey references.
I couldn't actually replicate OptiKey#783 but it's best to be explicit about readonly access.
Comments hadn't been updated with changes to strings
This error 'page' previously inherited the window state (size etc) of the intended XML file which meant that sometimes the info and the back button were tiny Now we use a standard large floating window to display the error, with fully white text.
- Allow point and key subscriptions to be handled in parallel - Add appropriate logic to handle when each is appropriate - Make mouse action keys (left click etc) be lockable, with actions repeated when locked down.
Previously if you tried to select a point near the screen edge (right or bottom) then the cursor could flip back and forth while you were trying to select, which was very distracting. Now it stays flipped unless it needs to flip back on opposite side. If people don't like the "non-standard" orientations then we could make it flip back to "standard" over a larger region, so long as it's far enough away from the bottom right threshold that it doesn't flip while trying to fixate.
We now pass a TriggerTypes enum to distinguish between point, key and gesture events. The test semantics have not changed, just updated the relevant tuples. One test has been split into two for point vs key selection resets.
Several things from https://github.com/OptiKey/OptiKey/projects/2, commit messages speak for themselves