-
-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial libsoup async implementation #236
Conversation
Changes to use libsoup async functions on main cases. Now most `Translator` methods should just process data.
Doesn't seem to cause any slow downs so far for me.
Yeah, probably better to just leave it as is. Proxy users get broken TTS (lol) but not much we can do there. gTTS uses requests IIRC, so maybe it'll just work?
As long as we're using the Session helper class and every request is from the same thread, I don't think it really matters much.
Should be fine. |
Seems like it works just fine with a minor change. |
So, there are some issues...
There are others but I'll have to make sure, so I'll post them later. |
Fixed this and made me remove an unnecessary request when validating. |
Some api servers might require it
- Now checks if data received is valid. - The approach itself is still unfortunately broken. - Remove unnecessary import, fix styling.
That should fix all the weird re-translation issues. Hopefully, for good. Overall, this is very much working out fine for me. I think it might be the right direction to go. |
- Separate user selection and programmatic selection. - Give a function for programmatic selection and give option to not cause retranslation. i.e. to not emit user-selection-changed - Throw away no_retranslate.
8dfb7e3
to
6156f9c
Compare
cc78b00
to
2582bea
Compare
2582bea
to
ae71d18
Compare
1e7a2e0
to
0a03584
Compare
Add custom exceptions to handle possible translators errors Show better error messages when loading and translating
0a03584
to
1b9c08d
Compare
Changes to use libsoup async functions. Now most
Translator
methods should just process data.TODO
trans_queue
Notes and open questions
With this implementation all the JSON processing code is run in the main thread, test if this doesn't affect the app fluidity. If so, maybe we can rewriteSession.multiple()
and create other helper functions to run the processing callbacks threaded.We need to figure out what to do with the TTS code. We don't have time to re-implement gTTS. Should we just leave it as is?It's fine to make requests fromTranslator.__init__()
? Or should we figure out a way to make them fromDialectWindow.load_translator()
and makeTranslator()
only provide the needed urls and processing functions?It'sSession.multiple()
fine or should we make it run one task after another?