ConfigStore does now stricter section & key checks against Hatari
config, which broke debug UI config saving. Because debug UI is
likely to go away at some point (doing debugging from another process
has too many restrictions), do minimal fix (don't save follow-pc
option).
And return error from load function instead of proceeding if config
loading failed and there are no defaults given, as things would
definitely fail without even any defaults being there.
Otherwise Python UI crashes to assert after user has changed a
configuration value, and either tries to exit, or re-run Hatari, and
OKs Python UI's suggestion of saving the changed config settings
before that.
* This was caused by Hatari v1.6 config variable name changes and those
new variable names missing type prefixes.
* Fix is using variable type mapping (conftypes.py) generated from
Hatari configuration.c file instead of inferring the types from
the (missing) name prefixes.
load/save features. If config changed in UI, give a temporary
config file to Hatari whenever it's re-run
- Fullscreen isn't anymore a toggle as user cannot use this
option if Hatari is fullscreen... Removed fullscreen config
option handling as it will be changed also directly from Hatari
- To support drag&drop for the UI, it forwards non-option args
(floppy name) to Hatari from the UI command line
- Disk image and joystick settings to separate dialogs
- Add dummy paths and peripherals settings dialogs
- Check that Hatari supports --control-socket argument
- Make dialog run() methods more consistent
- Python code compatible to Python 2.4 (I'm testing with 2.5
which accepts '()' for classes not inheriting anything) and
wrapper scripts to older SH (use exit when outside func body)
with keys named the same (shortcut and joystick sections),
needed to rewrite config handling to take this into account
- added joystick emu selection
- apply doesn't close trace settings dialog, only close will do
sections and capitalized True/False)
- add checkpointing to configuration and change changed
config variable checking/listing to use that. Checkpointing
will be useful for Hatari configuration dialogs
- generalize Hatari configuration handling code and move it to
to a new config.py file
- split Config class to ConfigStore and ConfigVariables classes
- ConfigVariables class makes accessing the configuration variables
nicer as they are now class attributes and have proper types
instead of being just strings. The code checks/enforces the Hatari
types (bool, int, string) on them
- ConfigStore class then takes care of loading/saving of
configuration and its changes
- Renamed ConfigMapping class left to hatari.py into HatariConfigMapping
and adapted it to the configuration handling changes