"power" becomes "powoer", seemingly delayed second press about unshaky HOT 34 CLOSED

@cperezabo Try v0.4.0 and turn on "aggressive mode" in setting to see if it can solve your problem.

from unshaky.

from unshaky.

@cperezabo Just wanna check how it goes?

from unshaky.

Can you open the debug windows, reproducing the problem and post the debug log here so I can look into it.

from unshaky.

I am trying to reproduce it but it is not happening now, as you already know it is very random! Sometimes nothing happens and sometimes it start failing repeatedly. As soon as it happens again I will record with the debug window and post it here!

from unshaky.

Oh and sorry for the title thing, I was so concerned about the issue itself I forgot finish writing the title

from unshaky.

Sure, let's see whether it is some issue can be fixed by software. Hope it is just you typing very fast :-). Otherwise, I kind of worry whether it is kind of next level hardware issue the bounce no long be restricted within a very short time, and making it hard to distinguish from normal key presses.

@cperezabo no worry, the title thing is totally fine.

from unshaky.

While I was writing the word "finish" it happened with the "n" and I wrote "fininsh", luckily I had the debugger opened (n key with 50ms)

from unshaky.

Kind of weird, it does not seem to be typing "finish"

from unshaky.

I have noticed debugger is not logging keys with 0ms delay, that's why you can't see the full "finish" word. Is this partial logging a by-design behavior or a bug? It would be easier to debug if you add a column with the value of the pressed key so you can graphically find the word. Just an idea.

from unshaky.

Oh I forgot that sorry. It was implemented as it is by-design but now I think it makes more sense to show all keys.

Edit: I can tell from the log, the keyup of 1st N and keydown of 2nd N are very close (32ms), which is shorter than 50ms, it should be able to cancel it. It is odd it did not do the job.

As for showing the word instead of the code, I should definitely implement it, thanks for the suggestion.

from unshaky.

If you set the delay to 50ms, the last "N" should have been dismissed. Can you try to set the delay of "N" to a very large value (e.g., 900ms) and press it quickly for several times and see whether some "N" are labelled dismissed? Maybe something is wrong with the event interception?

from unshaky.

I setup 900ms for R key and It was dismissed just the second time I pressed it. I didn't even do it quickly

from unshaky.

Now quickly

from unshaky.

When I uploaded the last image I saw something with my developer's eyes. I tried again with a large debugger window and after pessing R quickly...... Is it a pattern?

from unshaky.

Now with pressing "o" and "r" at a fixed pace

from unshaky.

Now pressing just "R" quickly, and then less quickly, and less quickly

from unshaky.

It seems to work as expected for the 5 screenshots you just uploaded... My guess is maybe the delay was not effectively set previously. Can you set the delay back to normal and see if the problem still persists?

from unshaky.

It's set back to 55ms as the rest of the keys. Problem persists. I get a key repeat after having press another key, randomly of course because I'm just typing and boom.

from unshaky.

I am starting to wonder whether it is vibration from the press on another key causes the problem. Right now there are "n" and "o" being effected as far as I know, any other keys?

from unshaky.

No I have delay set up for [c, e, i, k, n, o, r, t, space] and happens to all of those keys, but some of them are used more often.

from unshaky.

Sorry I still cannot figure out what the cause is. The only option right now is to keep debug window open to generate more log, and hope we can see some patterns.

This version of Unshaky below has key delay in the debug window, you can also build it with the latest commit.
Unshaky_v0.3.4_internal.zip

from unshaky.

I was writing "Hearts on fire" and it ends up being "Hearts ono fire". There it is the ghost "o"

from unshaky.

Wow, your “o” key has triple presses... I might have an idea to deal with it. Thanks for the debug info.

from unshaky.

I just installed it and will be checking it

from unshaky.

I think this "aggressive mode" should be the default mode when it is tested enough.

from unshaky.

Yes, I think that too. I have been using it since yesterday and it works flawlessly but something happend 1% of times, I got some duplicated. I was writing "I don't know" and got "I don't knoow"

from unshaky.

Take a look at the first ~6, don't know what's happening. Problem is almost cancelled btw. While writing this I got another extra "o"

from unshaky.

Writing "nos" I got "noos", I hope to have marked correctly, just to help.

from unshaky.

Great to know 99% of the time it works!

From the log the abnormal bounce occurred >55ms, which is longer than what I expected, and difficult to distinguish from normal presses. If you type fast. If it is only happening to your “o” key, try to set the delay of ‘o’ to something larger without mess up with your normal typing.

from unshaky.

from unshaky.

It is not before pressing the "n", instead it is before releasing the "n" which is fine.
The issue here is (see the screenshot) for the two "o" presses, the second one is obviously unwanted but since it is ~70ms away from the first one (>55ms), Unshaky won't block it. I would suggest you to set the delay of "o" to something around "80ms."

from unshaky.

55 is my longest delay possible because I cannot type google nor facebook. I guess I will have to live with it 😕

from unshaky.

I really hope it can block 100% of these, but your issue seems to be severe... and software solution might not be able to deal with it anymore...

PS: thanks for helping improve Unshaky!

from unshaky.