Danesprite on doc-changes
Danesprite on master
Make mention of AGPL v3 license… Merge pull request #356 from di… (compare)
Danesprite on doc-changes
Make mention of AGPL v3 license… (compare)
Working with function context I had a thought. This could be true all context Classes.
Perhaps it could be a
mode parameter to the base Context classes. Based on the type of mode dictates when that context is processed.
call Something similar to
get_engine().process_grammars_context() But just for those that are
call not all Context and it would only be processed when the function is called.
utterance - The default mode - process every utterance
With timer and call It might allow for functions that you normally would not want to process per utterance due to performance reasons.
Eva'scomes out as
@tieTYT It sounds like this is just the way DNS works and you have to train misrecognised words separately using "train word".
Does that usually fix the problem? Let me give an example, I've never been able to get Dragon to type
Eva's. Even after training.
Did you try dictating it and training it in a sentence rather than an individual word?
correct thatInstead of the
train wordNo as a individual word but the surrounding sentence gives Dragon
correct thatthe context of how and when It should be recognized. I've only found the train word to be effective for small changes in pronunciation. For words that sound similar I've had to train them as well.
I think some of you in this channel might like this example command module. It demonstrates window movement with Dragonfly's
Window.move() method, including its optional argument for animating window movement.
The available commands are as follows:
move [this] window here [animated]
center [this] window here [animated]
move notepad [window] here [animated]
center notepad [window] here [animated]
BringApp(editor, 'test_text.txt', focus_after_start=True).execute()
BringApp(editor,'test_text.txt', filter_func=lambda window: window.maximize(), focus_after_start=True).execute()
filter_funcis obviously not meant for the purpose described above.
maximize_window = Function(lambda: Window.get_foreground().maximize()) action = BringApp(editor, 'test_text.txt', focus_after_start=True) + maximize_window action.execute()
@/all Dragonfly2 version 0.32.0 has now been released. This version mainly includes bug fixes. There are also a few improvements to the clipboard toolkit. All notable changes are listed in the changelog here: https://dragonfly2.readthedocs.io/en/stable/changelog.html
You can upgrade by running
pip install --upgrade dragonfly2.
We could add an extra argument, but this is flexible and already works.
I wouldn't mind mind submitting a PR for
BringApp To add an argument
post_func that allows for function to be run if BringApp is successful. I could do that in a couple days.
However if you don't think it's worth it's time I will stick with your suggestion :-)
def launch_editor3(editor='notepad'): # if editer is closed get_matching_windows IndexError: list index out of range # if editer open background not maximized it will maximize # if editer open minimized it will maximize from dragonfly import BringApp, Function, Window BringApp(editor, 'test_text.txt', focus_after_start=True).execute() editor = Window.get_matching_windows(title='test_text', executable=editor) # IndexError: list index out of range if not editor.is_maximized: editor.maximize() def launch_editor2(editor='notepad'): # if editer is closed it will maximize # if editer open in background not maximized it will not maximize # if editer open minimized it will maximize from dragonfly import BringApp, Function, Window BringApp(editor, 'test_text.txt', focus_after_start=True).execute() Function(lambda: Window.get_foreground().maximize()).execute()
I had a question about dragonfly -- curious how you all solve problems like saying "right four" which becomes "right for" often (when trying to move the cursor right four times). The same thing happens when saying "enter" and a few other words.
Do you have any advice on navigating this - is there a way to help Dragon(fly) recognize "right four" instead of "right for"?
@altosaar @daanzu I have noticed DNS recognises my commands like this sometimes.
Dragonfly's English-language integers were changed a little while ago to include alternatives "to" and "too" for the number "two". I think it was a mistake to add these, however, and will be removing them in a future version because they are confusing.
Maybe you have noticed this behaviour @lunixbochs?
Yes, DNS certainly has its issues. It is good that Kaldi doesn't have this or certain other issues. Those alternatives for 2 are annoying when you want to type the word number "two". My mistake for not thinking the changes through.
I notice that SAPI 5 has a slightly different, but related problem recognising Dragonfly's "oh" alternative for "zero".
I wonder if anyone in this channel would be interested in my enabling Dragonfly's X11 integration to work remotely, e.g. via SSH forwarding. I haven't actually tested it, but I suspect it may work in some environments if the required programs are available locally. Certainly it could be made to work more nicely on Windows and macOS.
It is rather late here, but it seems to me this is an alternative way of achieving what Aenea does: communing with the remote X11 server directly.
Mine too, at least on my Linux box. I'll see what I can do.
I think this has the potential to be less brittle than Aenea and, perhaps, easier to set up. Much more so if Dragonfly used python-xlib for everything. It would also be much more flexible than Aenea in certain scenarios.