Dipping our toes in setting up studio config defaults via RV_PREFS_OVERRIDE_PATH/RV_PREFS_CLOBBER_PATH environment variables. We’re currently cross-platform (macOS and linux), so ideally we’d prefer to manage a single studio/project-level set of overrides irregardless of the platform that RV’s running on. Seems like the PATH vars need to be set to dirs and not the fully-qualified file paths to the config files? In the linux case it wants an “RV.conf” filename whereas Max is expecting a “com.tweaksoftware.RV.plist” file? Is there any way to consolidate this into one global config or are we resigned to maintain a separate set of preferences for each platform?
3 Likes
Hi Nico,
The short answer is, no. You need to maintain one for each OS. Yes, the path is set to a path rather than a file, this allows you to have the same environment variable for all OSes with all the prefs in the same folder (since they don’t have file-level name space collisions). Note that these paths should be considered similar to any path variable (like $PATH) were you can have multiple directories separated by :'s, all files found in each path will be read in order and concatenated (or replaced where keys collide).
I started to go down this path of getting us to a single file, however when investigating it with the principle engineer, the different formats work best for OS caching. Specifically MacOS caches .plist pref files differently than other file formats. Beyond that we have not investigated further. Studios are generally pretty anxious about any increase in startup time, and while this is probably a very small contribution, we didn’t feel it was an overall improvement if it could contribute to a longer startup time for the benefit of maintaining a single file.
I might be able to track down the format specific changes between the formats (I think it just comes down to handling how the groups get formed). With that you could make a format translator for your deployment mechanism. Would that be valuable or just too much work?
5 Likes
Hi Mike, since I’m planning on wrapping this into a Rez package anyways and this comes with an explicit pre-deployment build step I imagine I could include any prescribed translation steps you recommend. For our purposes conf->plist seems like the better option, but let us know if for some reason it’s easier to use plist as a starting point.
1 Like
Nico,
The two I’ve found references to are the platofrm-specific limitations (which aren’t all that limiting)
https://doc.qt.io/qt-5/qsettings.html#platform-limitations
As well as what groups can contain when it comes to special characters, I think there are differences in groups containing slashes; and that’s where I’ve seen trouble.
Beyond that, it might just be possible, for most cases, to load one file with QSettings and output it with another format by explicitly setting the file format.
-Kessler
2 Likes