1. Sending back a spurious CredentialsError() to check it's now handled,
but other issues blocking the code from getting there currently.
2. Move the "Update suit data from CAPI" call into the AppWindow
handler.
3. Move some more of the old query() exception handling into the worker.
4. session.query() no longer returns anything, and neither should
anything that calls it (like session.station()). This is going to
take quite some unwinding and code moving.
Due to main app being Tk we can't just use Python async functionality.
So instead we have a class to hold a message and optional exception.
And instance of that goes into a queue.
The reading of that in the main thread is triggered by sending a Tk
event.
Much more to come.
The file has:
1a. class Session - Frontier Auth
1b. class Session - CAPI queries
1c. class Session - Utility functions (to do with CAPI query data, but
not directly about *making* those queries.
2. Some non-class utility functions.
The former will be used by the latter, so this makes more sense when
reading the code.
In general I'm going to ensure there are two sections to this Session
class:
1. Frontier Auth code.
2. CAPI query code.
Yes, ideally I'd split it into two classes. But that kind of
refactoring isn't for *this* branch. I just want things straight in my
head for the "make CAPI queries run in a thread" changes.
Docked at an EDO settlement means CAPI says we are, but we've forgotten
monitor.station because there's not enough Journal information and too
many corner cases to be *sure* of re-using old data.
ConnectionErrors are expected and not something we can fix. The
exception handler that was catching these previously is a catchall
intended to stop EDMC as a whole from crashing from something
unexpected.
Closes#1082
The old "Error: Frontier server is down" can easily be confused as "game
servers are down". The new version calls out the CAPI specifically.
Closes#585
* Expand on the docstring to point out extra queries might be made.
* Add checks for lastStarport and then name within that being properly
present and set.
This is caused, at least on Odyssey Alpha Phase 3, 4.0.0.20, by:
1. Jump to a new system.
2. Don't dock yet.
3. Cause CAPI pull with 'Update' button.
4. The PTS CAPI server is returning:
"lastStarport": {
"faction": "",
"id": 3221604096,
"minorfaction": "",
"name": "",
"services": []
},
So actually we need to decide it's not sane at all.
I've gone with 'None' for when there's no data, rather than {}. That
makes for simpler checks on if there is data (a dict.get('foo') only
checks for that, not the dict structure otherwise).
If no 'suit' in the data we assume no Odyssey, but otherwise plough on
with dict.get() statements as they'll default to None if it's not
present.
*Users* of this monitor.state[] extra data get to choose what to do if
some data is present but not other.
