You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some current outstanding limitations with Castor and Dragonfly both interact programs by emulating keystrokes. This is just to name a few issues.
Reliability of IDE of performance different system configurations and IDE versions. This introduces variables such as command execution latency.
Castor is completely unaware of the IDE environment.
Dragon NaturallySpeaking has an upper complexity limit on Grammars. After the limit is reached, a BadGrammar error will occur.
Limited keyboard combinations and not all functions can be called by shortcuts.
Developers often have highly customized keyboard shortcuts that deviate from the default application settings. Caster utilizes default shortcuts.
Some examples via Adom editor
find in buffer: R(Key("c-f"), rdescript="Atom: Find in Buffer)
Only a few relevant commands are useful within 'Find in Buffer' context, but Castor app specific commands are global within the application which decreases command speech recognition accuracy and increases grammar complexity. With Caster IDE integration would allow for limited command sets specified to IDE contexts or focuses.
"split into lines": R(Key("cs-p") + Text("Split Into Lines") + Pause(atom_palette_wait) + Key("enter"), rdescript="Atom: Split Into lines")
Not all IDE functions can be called via shortcuts or be easily re-created within castor. A attempt to work around this within Adom was to utilize command palette. While this extended my ability to trigger commands it introduced latency. To fast the wrong command would be triggered. Too slow it a decrease productivity. Indexing latency which based on system load, system specs, number of active plug-ins, and number of characters per command. We tried to mitigate this by using Pause(atom_palette_wait) but the variables in the latency were too complex. The same would be true of Studio Code.
Castor would contain IDE functions to pass to IDEs plug-ins/extensions for execution. For example "select all": R(Function(Send, cmd="editor.action.selectAll"), rdescript="Select All"),
Rest function calls or emulated keyboard shortcuts could be used based on the presence of the API server
Castor would listen for contexts or focus announced from IDEs .
Castor would store commands and functions based on IDE context or focus. Then activate the only relevant commands containing shortcuts or IDEs functions based the focus announced from the IDE.
API Rest server
Passes arbitrary function calls from Castor to IDE
Populated Context/focus from IDE's
IDEs plug-ins/extensions
Listen for and execute IDEs specific functions from Caster via API Rest server
Announce current contexts or focus to Caster via API Rest server
As a long-term goal extend functionality of IDE ( e.g. in Visual Studio Code adding numbers to IntelliSense list) The user would speak the number and the appropriate line would be selected and executed.
The text was updated successfully, but these errors were encountered:
Some current outstanding limitations with Castor and Dragonfly both interact programs by emulating keystrokes. This is just to name a few issues.
Some examples via Adom editor
Only a few relevant commands are useful within 'Find in Buffer' context, but Castor app specific commands are global within the application which decreases command speech recognition accuracy and increases grammar complexity. With Caster IDE integration would allow for limited command sets specified to IDE contexts or focuses.
Not all IDE functions can be called via shortcuts or be easily re-created within castor. A attempt to work around this within Adom was to utilize command palette. While this extended my ability to trigger commands it introduced latency. To fast the wrong command would be triggered. Too slow it a decrease productivity. Indexing latency which based on system load, system specs, number of active plug-ins, and number of characters per command. We tried to mitigate this by using Pause(atom_palette_wait) but the variables in the latency were too complex. The same would be true of Studio Code.
An overview that of the entire project goals.
Castor framework API integration
API Rest server
IDEs plug-ins/extensions
Listen for and execute IDEs specific functions from Caster via API Rest server
Announce current contexts or focus to Caster via API Rest server
As a long-term goal extend functionality of IDE ( e.g. in Visual Studio Code adding numbers to IntelliSense list) The user would speak the number and the appropriate line would be selected and executed.
The text was updated successfully, but these errors were encountered: