Open ranomier opened 10 years ago
An argument against this would be that such separation would make sure settings can be applied, but when a crash happens at that point, they are not saved yet, allowing starting Mumble with its previous settings. Then again, the save would happen after the apply anyway - even when saving on the apply button action.
One possible way to avoid "infinite crashing" when wrong settings are applied, would be to implemnt @ranomier's other request: Move registry config keys into an appropiate config file within appadata (#1360).
If we do that, we can store a known good config file alongside the real one.
Then we could allow users to load that config file after a crash. A dialog after the crash reporter, maybe.
Come to think of it, we could provide something like that already. Instead of doing it with the users own "known good" config file, we could do it with our defaults.
Actually doing this in practice would require us to structure our C++ static initializers and other initialization code such that things won't be initialized until after the crash reporter (and potential "config resetter").
Better, just save a copy of the config file before any change. Even if the user makes multiple changes before a mumble restart. If mumble is crashing because of the change or while startup with the new config, use the old one.
After a successful start or after a change delete the old one and make a copy of the current working again.
Something like that. (Example code)
if detect_crash() ist True:
rename_config("current", "crash_config_" + time.stamp()
rename_config("backup", "current")
load_config("current")
If user_makes_changes:
copy_config("current", "backup')
make_changes("current")
It would be much more suitable if mumble saves config changes when the user actually hits the apply button. It's just annoying to redo the whole setup if the system or mumble crashes in between, it shouldn't be like this.