search

openstenoproject / plover

Open source stenotype engine
http://opensteno.org/plover
GNU General Public License v2.0
2.35k stars 279 forks source link

OS X: Plover stops translating input till restart #484

Open jeremy-w opened 8 years ago

jeremy-w commented 8 years ago

Classification: Bug

Reproducibility: Eventually Always

Summary

Plover eventually stops translating input from my keyboard. I switch it off with {PLOVER:TOGGLE}, and then I go to hit {PLOVER:TOGGLE} to turn it back on, and nothing – I just see the normal key output, rather than Plover re-enabling itself.

Steps to Reproduce

  1. Fire up Plover.
  2. Leave it off most of the time, but turn it on for spurts, then back off.
  3. Turn output translation back on a while later.

Side note: I was able to repro more under my control (vs the random drop-outs I seem to see most of the time) by backgrounding the process with C-z and then foregrounding with fg. I noticed it stopped receiving strokes after foregrounding. Fixing it to be "background-safe" might fix this problem in general.

Random reaching not based on any actual examination of the CGEventTap stuff: Perhaps it has to do with taking too long to handle some input and the OS just kicking it out?

Expected Results

It turns back on.

Actual Results

Nada.

Version

I've been running HEAD (it's stable enough). Currently sitting on 403162ddcd032f842faee29387d7c7e48c90d7e4, which is reporting 2.5.8 in the About page. This has been happening for a while though.

Installed via GitHub clone, run via sudo python setup.py launch.

Notes

I haven't found any particular trigger for this behavior. Sometimes I'll flip it on and off a few times in succession, go to flip it back on without much time with it off, and it just won't come back up. :(

Could there be a relationship to #444 and the out-of-order behavior noted in some of the later comments?

Workaround

Quit and relaunch. This fixes it every time.

Configuration

OS: ProductName: Mac OS X ProductVersion: 10.11.4 BuildVersion: 15E65

jeremy-w commented 8 years ago

I'd be curious to know if anyone else using Plover under OS X sees this. I'm very much a novice, so I'm flipping in and out of steno mode a lot, and often very much out. I think that it's a keyboard input also matters here, which means most experienced users probably won't encounter it, since they'll be using more dedicated input devices. :\

morinted commented 8 years ago

I might have had this happen? Usually when Plover stops working, I'm in the middle of something and I instrinctively Cmd-Q and restart it, as silly as that is. So it may have happened with the Treal.

jeremy-w commented 8 years ago

Ah, weird, so you've had it drop out right in the middle of writing? 🙀

morinted commented 8 years ago

Maybe, like I said, I treat it more like a crash as many of my programs do, while coding and such.

benoit-pierre commented 8 years ago

Didn't we establish that, like with the Windows hook, taking too long to process the tap "breaks" it?

morinted commented 8 years ago

Yes, don't know why that didn't come to mind. Guess I got distracted by the mention of foreground and background.

But it's easy to reproduce this by adding a sleep in the suppression code. Not sure about my Tréal happenings, though.

jeremy-w commented 8 years ago

It looks like we broadcast the stroke notification synchronously. If we pushed stroke handling out of the immediate KeyUp callback, that should remove the heavy lifting of translation that is presumably blocking returning from the event tap callback sooner.

I'll need to learn how to profile Python performance to verify that's actually where most of the time is being spent before making any such change, though.

morinted commented 8 years ago

Can I assign this to you, @jeremy-w ? You could also take note of Benoit's work of the Windows multiprocessing solution.

jeremy-w commented 8 years ago

That would be great. I was hoping to get some time on this already, but I haven't had much dev time outside work lately.

Jeremy W. Sherman http://jeremywsherman.com/

El 30-04-2016, a las 13:03, Ted Morin notifications@github.com escribió:

Can I assign this to you, @jeremy-w ? You could also take note of Benoit's work of the Windows multiprocessing solution.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

morinted commented 8 years ago

Thank you :) It's all right, this bug doesn't seem to be hitting frequently and anyone using Plover for professional work on Mac will likely have a steno machine and won't be affected. Though, I'm not sure that's anyone but Stan and Glen.

morinted commented 5 years ago

Seems like this is still an issue for a user on the Discord. I'd like to investigate and see if I use keyboard mode if I get the issue. I've noticed some slow downs since upgrading to Mojave, and I'm wondering if it's related to power throttling or something.

cbondurant commented 4 years ago

I find that I also get this issue, I am able to consistently reproduce it on the currently released weekly build on debian by simply spamming the toggle key, it will eventually lock-up the program and plover will slowly cease to respond. This issue looks like it has not been looked at in a while, so I guess I am posting in hopes of boosting the issue?

SeaLiteral commented 4 years ago

I've had it happen on Ubuntu. But I've rarely toggled Plover on and off since I noticed it would sometimes get stuck when doing that. But I haven't updated Plover in the last couple of months, so it could be it's been solved in the meantime, and I wouldn't know. So yeah, it's probably not a Mac-only issue.