symconf/REFACTOR.md

53 lines
4.0 KiB
Markdown

- Require all app names be set somewhere in the app registry, even if no variables need to
be supplied (such as "gnome," which just calls a script based on scheme). This helps
explicitly define the scope of "*" for applications, and can allow users to keep their
config files without involving them in any `autoconf` call.
- `scheme: auto` is a valid specification, but it will always resolve to either `light` or
`dark`. "auto" is not a valid scheme choice when it comes to naming, but it can be used
when making `autoconf` calls to set palettes that reflect the scheme that is currently
set (just think of the analogous setting in the browser: auto just means to infer and
set the local scheme to whatever the system scheme is set to).
- Due `/call`, we no longer have explicit, hard-coded scheme commends in `set_theme.py`.
Calls to GNOME's portal or to MacOS system settings can now just be seen as another
"app" with a configurable script, reactive to the passed scheme option.
- Here's the palette/scheme spec model
* If specific `scheme` and `palette` are provided, files prefixed with
`<scheme>-<palette>`, `any-<palette>`, or `<scheme>-any` are matched, in that order,
for each unique file tail, for each app.
* If `palette` is provided by `scheme` is not, it defaults to `auto` and will attempt to
infer a specific value, yielding the same case as above.
* If `scheme` cannot be inferred when `auto`, or is explicitly set to `any`, only
`any-<palette>` file prefixes are matched. The idea here is that `any` indicates that
a theme file is explicitly indifferent to the specification of that option, and won't
interfere in an unintended way. The term `none` would work exactly the same here;
`any` seems like it might be misleading, indicating it will match with any specific
palette. In any case (no pun intended), palettes should create files with an `any`
scheme if want to be considered as a possible setting when the `scheme` is any option,
i.e., `light/dark/any`.
* The same goes for `palette`, although it will default to `any` when unspecified. Thus,
only commands/files that change `scheme` will be considered when `palette` isn't
given. (I suppose we could also consider an `auto` default here that attempts to
determine app-specific palettes that are currently set, and switch to their opposite
`scheme` counterparts if available. You could still explicitly provide `any` to ensure
you just isolate the `scheme` switch, but `auto` could allow something like a dark to
light switch that applies to gnome (only supports scheme), changes kitty to
"tone4-light" (a light counterpart the currently set palette is available), and
Discord remains the same (as a hypothetical app for which we've created a dark palette
but no a light one)). I guess the main takeaway with `any`/`auto` is the following: if
`auto` can resolve to the concrete option currently set for a given app, behave as if
that option was given. When `any` is provided (or `auto` fails to infer a concrete
setting), _isolate_ that property (either `scheme` or `palette`) and ensure it doesn't
change (even when another might, and doing so by only matching theme files that have
actually used `any`, indicating they actually deliver on the agreed upon behavior
here).
* If neither are given, (depending on what we decide), both would be `auto` and should
do nothing (simply determine the `scheme` and `palette` currently set, requiring no
updates). If both are `any`, this should also do nothing; `any` is meant to "freeze"
that property, so we'd just be freezing both of the possible variables. One or both of
these options could serve as a meaningful refresh, however, either re-symlinking the
relevant/expected files and/or calling the refresh commands for each apps to ensure
expected settings are freshly applied.
- Config TOML accepts either `config_dir` or `config_map`, nothing else and only one of
the two.
- Refresh scripts should likely specify a shell shabang at the top of the file