Accent colors and other related things could be loaded on startup as environment variables, so apps can just check a file in /run (or however environment variables are handled properly), but a fallback checking the config file will be necessary for compatibility. Also, an option to switch Accent colors on a timer like RGB motherboards and keybords.

[DrewNaylor]

I just think loading the Accent and theme (background) color names into RAM on startup as a file and/or environment variable will make it easier to later have apps update that color, both for testing and for if people want to override something with their own script without touching the config files. This may present an issue for the lockscreen though, but maybe that can just load from the config file, and the script can load things into RAM properly on login or something. Not accessing the storage for this may help some apps load slightly faster, but it might not help much other than being simpler for testing or if the user wants their accent color to change between every color of the rainbow (or colors in set themes that the user can create or will be shipped as choices, but maybe that should be in an Extras package when everything is split up) without constantly writing to their storage. Actually, that's a really useful idea, then on top of that, add a delay setting that lets how often it changes be set (with a warning message that pops up if an amount that's so fast it could induce a seizure is chosen by accident or on purpose). To help with this, there could be a list of colors that the user wants/doesn't want to have it switch to, and a way to add more than one custom color to the list (also the main list, since someone may want to keep more than the last 5 colors that were set). There should also be a way to fade between colors like many RGB motherboards and keyboards instead of instantly switching between them, if someone wants that feature.

Loading from the config file will still have to be done if the environment variables aren't set, so apps can be run outside Retiled (just fancier stuff won't be supported at all or as easily, unless the script is manually run but with the caveat that it could break stuff in an environment it's not intended for).

[DrewNaylor]

On the lockscreen, it might not be able to cycle through the colors without loading the set color cycle theme and manually changing the Accent color on a delay, but not sure about the Action Center. Maybe there'll just have to be a static, main color for that. But then, the Action Center will be able to change when logged in, so maybe it could do the same thing as the lockscreen, but once it sees that the environment variable is set, it switches over, or something.

When the screen is locked, the cycling needs to be paused to save battery life after fully switching to the next color (if fading is set, but to be safe it'll go to the next color anyway), and it can continue when unlocked. With Battery Saver, it switches to the next color and then pauses it until Battery Saver is off, similar to locking and unlocking above. Maybe a static Accent color can be done by saving the last Accent color before shutting down, that way the one on the lockscreen can still be dynamic every startup, even if it doesn't cycle until login.

An option to pause the dynamic color cycling should be added, with an item for it in an Accessibility menu in the Action Center. It'll also have a button in the Settings page where the dynamic color cycling is set up, plus a shortcut back to the Accent colors page (might be cluttery to add a button for pausing dynamic color cycling here, but if dynamic color cycling is a subpage, it could have its own link) from possibly the Color Accessibility settings page.

[DrewNaylor]

The page that allows dynamic color cycling to be configured will have to have radio buttons that let people choose whether to use a slider control with a minimum value that should be safe for anyone susceptible to seizures (would 5 seconds be too short?), and a maximum value that's not way too long (maybe an hour max?) so it takes forever to change the colors; or to manually set the exact amount of time (with a units dropdown) if the slider doesn't work (a time picker would be easier than a textbox, so I could use that instead). Note that both options have the same minimum and maximum limits, because I don't want to give anyone seizures by accident just because they can't read a warning message.

Also, when loading this setting from the config file, it will be automatically reset to the safe minimum setting if it's below that, then it'll be loaded, and this all happens in a script. This script will be written in Python, and it'll tell an SH (would be Bash, but that's less compatible) script which colors to cycle through from the command line with the requested delay in seconds (because that's easier than trying to do time in different units). To be safe, that script will also make sure the requested delay is 5 seconds or more, and if not, it'll set the delay to 5 seconds. (All this safety is to ensure someone can't just modify someone's phone's configuration to give them a seizure without doing a lot of extra work.)

I think the script that sets the colors when cycling could just sleep for the requested delay then set the environment variable and sleep again. Sleeping should start after the first color is set so it doesn't look like it's broken immediately, causing the user to turn it back off, though.