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.
* Disable warning output during configuration.
* Allow users to turn on warnings for ffmpeg and other internal projects.
* Add a new variable for easier ffmpeg version migration if we ever
* pursue that.
* `set_target_properties` can have multiple properties assigned in one go.
* Have version information be generated from CMake, not later plist preprocessing.
* Configure the plist file regardless of OS. This should be a safe command: following the example from the knut repository.
The old fashioned Info-StepMania.plist file can be considered deprecated
upon a full migration to CMake.
Added delay_save_cache to SongCacheIndex so that it doesn't write the entire cache index file after every song is loaded when loading songs.
Added m_SongsByDir to SongManager so that GetSongFromDir doesn't have to walk the entire list of songs.
Minor changes to when LoadEnabledSongsFromPref occurs and how SanityCheckGroupDir works to speed up loading.
Song::ReloadFromSongDir removes cache file to force an actual reload from the song dir instead of reloading from the cache. ReloadFromSongDir exposed to lua.
Reordered Actor::LoadFromNode to put Command first because that case is more common.
Course::GetTrailUnsorted reserves entries before starting to save time reallocating.
join in RageUtil calculates the final size of the concatenated strings reserves it to save time reallocating.
Added time log file to RageLog for profiling.
It is necessary to clear existing cmake cache and generate a new Xcode
project, following wolfman2000's instructions in ./Build/README.md
Witht that done, you can use the StepMania.xcodeproj generated by cmake
to successfully build a fresh StepMania.app and it properly logs the OS
X version.
There was code in place to log the OS X kernel version (14.1.0, for
example) to log, but it stopped working some time ago. "Mac OS X
unknown." has been logged for the last several releases.
This commit swaps out that C++ code for a some Obj-C which logs the OS
X release version (10.10.2, for example) correctly. In order to mix
Obj-C with an otherwise C++ file, I changed the file extension from .cpp
to .mm to make it Objective-C++.
At the suggestion of wolfman2000, I have updated
src/CMakeData-arch.cmake to reflect the changes in this commit; that
will follow in the next commit from me.
Dan Guzek