This adds a new class called AutoInc, which is a self-incrementing
integer that supports use as a context manager. AutoInc is used to keep
track of row numbers automatically for easy addition to config panes,
and the context manager adds a visual clue to where entries are on the
same row but different columns
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.
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.
* If no ui_scaling yet set, set it to 'default'.
* 'default' added to dropdown choices.
Note that you still need an application restart for this to take effect.
* EDMCLogging.Logger.get_streamhandler() method to get the
logger_channel so prefs.py can call setLevel() on it.
* The top-level Logger level is always DEBUG.
* The RotatingFileHandler level is always DEBUG.
* The StreamHandler level is as configured by the user.
* EDMCLogging now creates a singleton of EDMCLogging.Logger and its
associated Logger.
* plug.py tweaked to only import EDMCLogging where it's needed for
getting/creating plugin loggers, else `import logging`.
* new class `PrefsVersion` in prefs.py. A singleton `prefsSaved` (note
case) is created.
* When new preferences are added and require defaults on first run the
code should use:
`if prefsVersion.shouldSetDefaults(<prior release version>, [<optional old test>]):`
to check if defaults should be set in preferences. So if prior release
was '3.4.6.0' and you've added a new preference with defaults you should
call this with '3.4.6.0' as the first argument.
The <optional old test> is really only for historical purposes, as a
fallback in case no 'PrefsVersion' has yet been set in the user's
Registry/settings file.
* Any code that adds such a new preference **MUST** make changes to the
`versions` dictionary in the PrefsVersion class.
1. Add the predicted next version to the dictionary, with number one
higher than 'current'
2. Set 'current' equal to that new value.
Obviously if other post-last-release code has already done this then you
don't need to.
Failure to update the versions dictionary in this manner will lead to an
Exception being raised, and the code the preferences are for failing
(i.e. EDDN means no EDDN tab on Settings).
Closes#407
To allow users to sort out their plugins before EDMC itself moves to
Python 3.x warn them if any of their enabled, non-stock, plugins do not
have a plugin_start3() method.
* If any are found without support there's a popup triggered at the
end of AppWindow initialisation.
* Then the user can check Settings > Plugins to see a list of the
plugins without Python 3.x support.
First pass utilising 'futurize' to do most of the work.
There's an issue with ur'\"' in l10n.py which I'm not sure how to
properly fix.
This now has errors when hitting the 'Update' button.
* Stores disable_autoappupdatecheckingame in settings.
* If 'disable' is active then once you're in-game WinSparkle auto
check for updates is disabled.
* Whatever the state of the option WinSparkle auto updates are
(re-)enabled when you exit the game to Main Menu or fully.
* Using 'Help' > 'Check for updates' manually will still always work.
It has been difficult to test the code fully because it isn't easy to
get WinSparkle's registry data about last update check time set just right
to not check immediately, but to do so some reasonable time after you're
in-game and have confirmed the new option setting isn't easy.
Worst case people won't learn about an update until the next time they
run EDMC.
To allow users to sort out their plugins before EDMC itself moves to
Python 3.x warn them if any of their enabled, non-stock, plugins do not
have a plugin_start3() method.
* If any are found without support there's a popup triggered at the
end of AppWindow initialisation.
* Then the user can check Settings > Plugins to see a list of the
plugins without Python 3.x support.
