Open tylercal opened 9 years ago
I haven't seen this issue in a current version of dragonfly on Dragon13. Perhaps the changes could be limited to WSR to avoid unnecessary overhead.
I agree, ideally this logic could be put in just WSR as mentioned in my original comment.
I would imagine that you would have the same problem if you changed windows using the keyboard while using Dragon13.
I don't encounter this issue changing windows via keyboard either -- at least not in my just-now once-of adhoc test, and I change windows like that probably more than 50% of the time, even when using my dragonfly sets.
On Thu, Jul 16, 2015 at 1:25 PM, Tyler Elliott notifications@github.com wrote:
I agree, ideally this logic could be put in just WSR as mentioned in my original comment.
I would imagine that you would have the same problem if you changed windows using the keyboard while using Dragon13.
— Reply to this email directly or view it on GitHub https://github.com/t4ngo/dragonfly/pull/28#issuecomment-122079299.
And I see what you mean. I read your post, but didn't take the idea of "possible tighter engine integration" as a suggestion that some engine not need the fix. I don't know who besides you does, but for all I know it's many other Dragon users, perhaps 12 or lower. I cannot rule out my system is just functional through luck.
Right now when you change windows, the new context is not loaded until you issue a command (and the set of commands is for the context you came from).
My solution needs tighter integration with recognition engines:
Ideally the foreground and title change hook would be contained in the engine library, but I couldn't get the hook to last when I put it in there. It only seemed to work on the main loop for me. My Python-Windows-Fu is not strong enough for a less hacky solution.
Never the less, this makes dragonfly WAY more usable.