Inclusion of Dragonfly code in dtactions
Opened this issue · 12 comments
I have (finally) updated the actions-only Dragonfly branch used in this repository as a sub module. From here, we could add that version into this repository properly.
We could alternatively make changes to Dragonfly that remove or group as "extra" dependencies that won't be used by code in this project, and then use Dragonfly here as a dependency. This would be related to dragonfly2 version 1.0.0 and dictation-toolbox/dragonfly#247. I bring up this option because I'm not sure that I can commit to maintaining separate versions of Dragonfly's OS action code.
I would be interested in your thoughts on this @quintijn and @LexiconCode.
It's too much of a burden to maintain 2 separate versions of dragonfly.
We could alternatively make changes to Dragonfly that remove or group as "extra" dependencies that won't be used by code in this project, and then use Dragonfly here as a dependency. This would be related to dragonfly2 version 1.0.0
Forgive my ignorance but this seems backwards. Wouldn't Dragonfly have dtactions as a dependency?
In fact we could do extras dtactions to include only the modules that are needed by a project.
Forgive my ignorance but this seems backwards. Wouldn't Dragonfly have dtactions as a dependency?
Yes, it is a bit backwards. It could be changed later on (if/when this is released as a package?) so that Dragonfly uses dtactions instead. The code could be moved over then. However, there are additional problems (see below). dtactions could still use and expose (for convenience) the relevant Dragonfly classes, functions, etc in addition to other functionality of the Natlink project, for example.
In fact we could do extras dtactions to include only the modules that are needed by a project.
I suppose we could do that. Dragonfly has quite a few dependencies that could be made optional, however. If they were made optional, there wouldn't be many extra requirements compared to those needed for Natlink. A related Dragonfly issue for that is dictation-toolbox/dragonfly#238.
One other issue on moving over Dragonfly's code is that of where the relevant sections of Dragonfly's documentation would be moved. This is especially problematic since the documentation and code reside, for the most part, in the same Python source files. Given that certain actions like Mimic and Playback cannot be moved over and still have to be documented somewhere, I'm not sure this would be worth the hassle. It would also be rather confusing to users if most of the actions were suddenly located and documented somewhere else.
Sorry, can't say much about this. I would like to start an installed version soon. Could you agree to ask Doug Ransom to do this, in analogy to natlink, vocola and unimacro. See for example in the natlink repository. I am experimenting with flit install for testing things. This flit install installs with symlinks in the site-packages directory. Seems to work very well, but I have some migration things for natlink itself.
How about version numbers? Natlink for example starting with 5.0.0, incrementing the latter 0 each time a test install is performed? If a release is made, go to 5.1.0 and then continue?
In regards to version numbers. I wouldn't mind seeing it 1.0 since this is a new package even though it's more mature coming from other projects. I'm totally flexible on that thought though. Looks like some work has been done to package in the following branch makeflitinstall. Not sure how that works with submodules and its dependencys. Where to host documentation is a good question.
As Danesprite mentioned certain actions are speech recognition framework related such as Mimic and Playback not OS related like most actions. If this is truly going to be its own independent repository beyond dragonfly going to have to have its own documentation. Something to give some thought about.
Perhaps splitting actions into 2 categories speech recognition and OS interaction The speech recognition could be hosted directly on dragonfly and this reference for OS interaction could be linked to this repositories documentation. It would be nice if we could seamlessly integrate them but some more research is needed to see if it even possible.
@Danesprite If I'm understanding this right Link to Other Projects’ Documentation With Intersphinx might be a way to make documentation seamless between dragonfly and dtactions.
The changes in the makeflitinstall branch look quite promising. The flit develop options seem similar to the -e/--editable options for pip install.
@LexiconCode As I said above, I am opposed to splitting Dragonfly's code or documentation into separate repositories, projects or packages. In my view, this is not worth the hassle. I would still prefer to simply reduce the number of hard requirements for Dragonfly itself, allowing use of it as a library for the action functionality.
Still, thanks for mentioning this intersphinx Sphinx extension. It seems more robust than using simple URLs to other projects. The documentation of dtactions should be able to use that to reference the relevant sections of Dragonfly's documentation.
@quintijn I can help set up the documentation for dtactions if you like, I'm quite familiar with Sphinx.
As I said above, I am opposed to splitting Dragonfly's code or documentation into separate repositories, projects or packages. In my view, this is not worth the hassle. I would still prefer to simply reduce the number of hard requirements for Dragonfly itself, allowing use of it as a library for the action functionality.
Yeah I will defer to your wisdom on this. Trying to think outside the box that there's different ways we can make it work. That would be really helpful for setting up the initial Documentation for dtactions. Is there a decent editor for Sphinx outside of VS code?
Okay, I'll see about setting up the documentation in a new branch then. 👍
Regarding editors, there is a major Emacs mode for reStructuredText (RST) — the default markup language used by Sphinx. I only really use the syntax highlighting part though. If VS Code does that for you, then you only need a terminal open to (re)build the documentation (e.g. with make.bat html) and check for errors after you make changes. There also may be extra VS Code community extensions for RST out there.
I also occasionally use the rstcheck command-line linter for checking individual RST files. It can be installed with pip install rstcheck.
Sorry folks to have been off this discussion for so long.
About the sendkeys issue: dtactions now depends on Dragonfly.
The same functionality has been written for Vocola, and could be used via natlinkutils.py in the natlink repository. As a replacement for natlink.playString. This was the SendInput module, working together with ExtendedSendDragonKeys, written by Mark Lillibridge, the maintainer of Vocola2 (the Vocola version for Dragon on Windows). Mark is back on the scene.
However, I could not get Mark's work running, and found the Dragonfly module did the same without problems.
I think it would be good to ask Mark what would be lost if the Dragonfly modules are adopted. For now they are a bit entangled in more functionality than sendkeys needs, is my impression.
What do you think about trying to get the best out of these two modules?
A long time...
Maybe trying to include Dragonfly things in the dtactions repository is too ambitious.
It was tried/started because the Dragonfly sendkeys module seemed to do better than Vocola's version. Now the sendkeys.py module in this repository uses vocola's version.
Are there other concrete things that we want to unify right now?
Yes, too ambitious, perhaps. I think probably these libraries/tools differ a bit too much to really be unified. Dragonfly does things one way, Vocola does things another.
End users can always install and use Dragonfly directly for its actions. This is partly why I have been trying to reduce its requirements.