Revised everything and have now setup the new options menu for the
default theme in english mode ONLY (as of now). Use of the new options
menu requires theme modification
I moved a MESSAGEMAN:Broadcast() call so that it only broadcasts the setting that has been saved. This seems more sensible to me, but it is possible I'm misinterpreting the original design here.
Feel free to merge or not merge this commit. :)
As noted in my previous commit message, I think ThemePrefs.ForceSave() can safely be deprecated. Since many novice themers look to default when learning, I think it's better to use ThemePrefs.Save() as the system was originally designed.
I moved the ThemePrefs.Save() call out of ScreenTitleMenu decoration to ScreenOptionsService in. This seems safer to me; Pay/Freeplay never hit ScreenTitleMenu which could be another reason ThemePrefs would never get saved.
Additionally, moving the call to ScreenOptionsService in also seems to have fixed a bug where switching themes via the Appearance Options service menu would cause the new theme to inherit all of the previous theme's ini settings. I'm still not entirely sure why.
I've done a fair amount of testing with this.
I've tried deleting the ThemePrefs.ini file outright and booting fresh into both default and Simply Love. In both cases, the ThemePrefs.ini file is written when StepMania exits or when the user hit ScreenOptionsService, whichever comes first.
I've tried switching between various themes, including those that did not use ThemePrefs. I haven't seen any sections being created erroneously and themes that do use ThemePrefs don't seem to inherit the previous theme's settings any longer.
Still, it *very* possible that I've missed some edge case(s) and is probably worth a few people testing before merging.
The ThemePrefs table contains several functions and single standalone variable, NeedsSaving. When a themer calls ThemePrefs.Save() the system will check the status of NeedsSaved to determine whether it really needs to save or not. This is by design to prevent unnecessary writing to disk.
As far as I am able to discern, NeedsSaved would never be anything but false due to scoping within the ThemePrefs table. This commit properly scopes that variable as it used within the functions.
It looks like ThemePrefs.ForceSave() was added as a workaround; it didn't check the status of NeedsSaved and just always saved, "no matter what." Though it seems safe to outright remove ForceSave(), I'm leaving it in for compatibility. Consider it deprecated I suppose.
false is a perfectly valid setting for one of SM's ini files. The code here needs to ensure that both the key (string) and the value (string, numeric, boolean) read from file exist. It would previously halt if the value was set to false. This fixes that by explicitly checking for nil.
Kyzentun