A_D had accidentally used 'ClickCounter' for this when their folder name
was 'click_counter'. This lead to using a very bare `logger` which
still used our defined format leading to things blowing up when there
was no adapter to handle `qualname` format string.
Else at least one caller to .station() blows up when it can't find the
commander data.
The call has to be to .station() so as to populate the market/shipyard
added dictionaries.
* Correct use of error[0] to just error.
* We don't want methods not referencing self to be static in this case,
so annotate them.
* Take suggestion of "if v == []:" equivalent to "if not v:".
* Preserve CAPIData typing throughout filter_ship().
* CAPI Data really is just a Dict. Define a custom type so it could
easily be a class in future with minimal edits.
* Auth.refresh() *can* also return a str (Access Token).
* Catch specific (but still quite loose) exceptions in Auth.refresh().
* Set self.server in Session.__init__.
* Remove some extraneous () on conditionals.
As we might run into some special cases with users we need to log in
more detail what the locale is around our changes.
NB: Also contains some misc. PyCharm-enacted formatting changes, white
space, wrapping etc.
tkinter ends up calling something where utf8 characters won't work
because of the windows encoding, e.g. cp1252.
We can't set encoding just for the dialogs, as it's not thread safe. So
we'll just set it at startup instead. Utilising:
locale.setlocale(locale.LC_ALL, '')
to get things set up initially, so we can properly retrieve the language
to go with the encoding on the subsequent setlocale() call.
There are cases where a station/FC doesn't have outfitting modules or a
ships list. Let's make the checks happen in both those functions and be
extra paranoid with some logging.
Closes#671
If we use the last configured value then the width of the Scale bar
changes as per the user's last setting, even though they might not have
yet restarted for all the rest of the UI to resize.
So if at startup tk-scaling is 1.33 then a user configured 200(%) will
set it to 2.66 for this run.
* Low end of scale bar set to 10, not 0, because now 0 makes absolutely
no sense.
* In theory the width of the scale bar, in pixels, is now also correctly
scaled.
Using a Tk.DoubleVar() with a locale where a comma is used as the
decimals separator leads to internal tk code recording values with the
comma but then other tk code not accepting that back, so it always
thinks the value is zero and the scale slider can't be moved.
Ref: https://stackoverflow.com/questions/45289237/tkinter-scale-slider-with-float-values-doesnt-work-with-locale-of-language-that
* Change to storing as a REG_DWORD under 'ui_scale' not 'ui_scaling'.
* Change all the code, except the call to *set* the tk scaling to use an
integer, with 100 = 100%, i.e. equivalent to the old 1.0.
* Update strings slightly, so translations will need updating too.
NB: The theme.default_ui_scale value for plugin authors to query is
still the float that tk returns.
