Closed CatOfTheCannals closed 1 year ago
Hi Dane, thank you for your help!
I've been trying to run your code on my laptop with Caster but it seems that the Dragonfly's version we are working with (1.0.0) is not compatible with Caster, which works only up to "0.35.0".
I encountered two problems with running the code on my laptop with Caster. The first was an easy fix, but the second has me puzzled.
The first problem I ran into was the change of interface for Dragonfly's parameters. I hacked that by changing Caster's running script. The second issue I'm running into is the following:
.DistributionNotFound: The 'dragonfly2>=0.29.0' distribution was not found and is required by the application
I've made sure I erased dragonfly2 from Caster's requirement files and manually installed my local copy of Dragonfly (pip install -e ../dragonfly
) with your suggested changes on the virtualenv I'm using.
The error does not kill the process but it seems to not be listening to voice commands.
I wonder whether this new version is the one we should be working on and, if that is the case, how much work does Caster need to catch up to it. To ensure timely delivery of the feature, we could consider incorporating your changes into a version that is currently compatible with Caster (0.37.0), and then work on adapting Caster to version 1.0.0.
Sometime Friday I will try to take a look at this for Caster.
Hi @CatOfTheCannals,
Sorry to hear you've had trouble testing these changes.
I believe I can explain the confusion with version numbers. Dragonfly version 1.0.0 is not out yet. Version 0.35.0 is still the latest version pip will normally install.
I think the second problem with Caster is a distribution name conflict. You might be able to fix it by locally changing line 81 of Dragonfly's setup.py file and then reinstalling:
name = "dragonfly2",
No need to change the Dragonfly version targeted by Caster. This won't be necessary when version 1.0.0 is released, as it will be available with either distribution name: dragonfly or dragonfly2.
Can you explain the first problem you ran into, the one related to "the change of interface for Dragonfly's parameters"?
Hello!
Changing the name of the package solved the problem, thank you 😄
The first issue I mentioned, regarding dragonfly's interface, occurred because the option "engine-options" seems to now be called "engine-option" and only accepting one option, instead of a dict of options. I don't know if this is the cleanest way to workaround it, but I changed the command to:
python3 -m dragonfly load _*.py --engine kaldi --no-recobs-messages --engine-option "model_dir=kaldi_model" --engine-option "vad_padding_end_ms=300"
In other news, I have validated that your proposed changes effectively enable the use of the command key for writing shortcuts!!! I'm already able to open new tabs and windows. When I set to work on adapting more rules I found out that some of them require the use of function keys, which in OSX can only be pressed with a modifier key called fn. I don't normally use these and I still haven't analyzed the usefulness of the shortcuts that require function keys. I'll be doing some research and understand if we need to support for that modifier key. More news coming soon!
Glad I could help. :-)
Ah, that interface change. Well, I am open to reversing that. I had thought it was cleaner that way, using the short form ('-o') instead. Some programs handle this sort of thing this way, some do it the other way. What do you think, @LexiconCode? I can change it back if you want.
Good to hear you're happy with the proposed command key modifier. As for the Fn key, I don't think it can be emulated. As I understand it, that key functions like a hardware switch which modifies keypresses before the operating system receives them. There is no virtual keycode for it on Windows, and no X11/Xorg key symbol for it. I don't think there is a programmatic way to press it on OSX either.
In any case, it should always be possible to emulate the keys the operating system receives. When writing Dragonfly Key
actions for such shortcuts, you'll need to determine the actual keys received by the operating system. I'm not sure of the best way to do that on OSX.
I would be fine with accepting a dict or any other type allowing for multiple engine options.
Okay then. I think I'll revert it to how it was before, since Caster already passes engine options that way.
@CatOfTheCannals, before I merge this PR, do you think there should be aliases for the option key, too? Or are the ones for Alt sufficient?
Hello! Sorry for the late reply. I've been quite busy. I can confirm both the function keys and option modifier key are working as it is:
'O': typeables["alt"],
so everyone knows to use and interpret the correct modifier key.I believe this is all that's needed to get the OSX shortcuts up and running, so I'll get to work on them and hopefully submit a pr to caster soon. Thanks for all your help guys!
I've added aliases and Key
prefix characters for the Alt key, too. Sorry it took me so long! I had forgotten about this.
Thank you for the pull request, @CatOfTheCannals. There are two problems, however.
First, m could be mistaken as an alias for the Alt or "Meta" key. Since
Key
specification strings are case-sensitive, capital C would work as a more sensible shorthand form. Capital S could be added, too, which would be appropriate for the "Super" key on X11.Second, your changes to the typeables.py file would, if merged, break the library for Windows and X11. Typeables for the left and right Command keys should instead be added as aliases of the Windows/Super keys. Using
key_symbols.LSUPER
andkey_symbols.RSUPER
in this file instead would render your changes to _pynput.py unnecessary.