Rewrite of regolith styles

Overview

regolith-styles is the package that provides a set of files read by Xresources that define (mostly) visual style elements used by i3, i3xrocks, rofi, and other desktop components. The visual appearance of Regolith can be updated via 'looks' which are comprised of a subset of Xresource files that change these values for a subset of UI components.

Current Problems

Organization and Parsing of Xresource files

The general idea of Xresources as global key/value pairs used for system configuration works well. regolith-styles was initially created with the idea that there would be one default look, and that other looks could be added over time. While this works, the default look is tied directly to the regolith-look style, rather than provides as a look as others. This makes the system overall more difficult to reason about, as the "edges" are implicit. More significantly, the default occupies the root of the styles directory in the /etc tree. The extension method requires that the root Xresource values are overridden such that a the configured look's files are referenced via include declarations rather than the default. This convention was created before the notion of Xresource overrides was developed. Xresource loading and look selection should be updated to take advantage of the Xresource overrides form of extension. As it relates to the package management system, multiple looks are able to be installed on the same system concurrently, so the reliance on one and only one file to determine the correct look does not apply here. Rather, an Xresource value itself needs to be used to determine the user-specified look to load. In the current version, look loading is implicitly determined in the regolith-session-init script which looks for ~/.Xresources-regolith and loads it if exists, otherwise falls back to /etc/regolith/styles/root.

Hard-coded location of Looks

There are some implicit conventions to how looks are loaded (e.g. assumption that all looks will be installed in /etc/regolith/looks/[name].)

Arbitrary color mapping definitions

Regolith's early versions did not support overriding of Xresource values. The initial styles were built to work with the Solarized color scheme. Later, more color schemes were added but the common names which all color schemes must reference stuck to the Solarized naming convention. There are various open source projects which provide color themes via Xresource mappings, such as base16. If Regolith's color Xresource convention changes to adapt something like this, users can freely select from a very large set of existing color schemes. Additionally, users wanting to add new schemes can utilize documentation and troubleshooting from those projects.

Coupling of Upstream Components and Xresource configuration

Rofi is a global modal dialog utility heavily used in default Regolith for user-initiated workflows, such as launching an app or searching for a window. regolith-styles defines some elements for Rofi by default, so that Rofi's look is consistent with the desktop as a whole. However if a user chooses to use something other than Rofi, the Xresources definitions cannot be removed. They are coupled to the looks. Ideally Xresource snippets or partials could be provided by a UI meta package such as regolith-rofi-config such that the Rofi-specific Xresource keys and any default values that may not be set in looks can be defined.

Unnecessary Variation in Names

The styles convention relies on #define preprocessor directives to map values to specific Xresource keys. These mapping keys vary by name for no reason, adding unnecessary complexity. Example: gtk_theme -> gnome.gtk.theme.

Poor HiDPI support

Some UI configuration such as Rofi specifies pixel values for window dimensions. This causes HiDPI displays to have abnormally small windows. Ideally a Look's configuration would seamlessly work with various screen densities without tweaks.

Proposed Changes

• Rather than predicating on file existence of ~/.Xresources-regolith to determine the loaded look, Xresource loading will be simplified by simply loading any Xresource partials found in /etc/regolith/Xresources.d, and then ~/.config/regolith/Xresources if it exists, then, loading an Xresource file defined by the value of Xresource key regolith.look. If this key does not exist or the file path is invalid, the default look (guaranteed to exist via package manager policy) path will be substituted (/usr/share/regolith-look/minimal/root).
• The regolith-styles package will be deprecated. regolith-look-minimal will contain a basic set of Xresources to define a default style with the minimum possible set of files and dependencies (no background image, no dependencies on fonts not already on system if possible). regolith-look-minimal will always be installed on a Regolith system. Other looks can be wholly contained via include directives from /usr/share/regolith-look/minimal/root if desired.
• /etc/regolith/styles tree will be deprecated.
• All Regolith packaged looks will be in /usr/share/regolith-look/[look name].
• Update all references to color mappings to use a popular convention such as base16.
• Regolith Looks will be broken into two forms: Looks and Component Mappings. Looks define the colors, themes, etc that set the visual appearance of a look. Component Mappings map those visual definitions to specific applications, for example i3-gaps. Rather than, say regolith-look-cahella vending both Look definitions and Component Mapping definitions, it will only ship the former. The i3-gaps metapackage regolith-i3-gaps-config instead ships the i3-specific Component Definition. In this way, looks can be extended to be used by arbitrary components (e.g. Polybar) that a Look author is entirely unaware of.
• Rename preprocessor includes to exactly match Xresource keys, substituting seperator char . for _.

User-facing Changes

Look installation and selection will continue to work as-is from a usage scenario. Any looks from Regolith 1.x will need significant changes in order to work with Regolith 2.0. It is to-be-decided on which looks will be ported.

regolith-session-init logic summary

Before

• Load look (all look files via include declarations) either in ~/.Xresources-regolith or /etc/regolith/styles/root.

File Layout

/etc/regolith/styles/root
/etc/regolith/styles/rofi
/etc/regolith/styles/i3xrocks
/etc/regolith/styles/st-term
/etc/regolith/styles/gnome
/etc/regolith/styles/i3-wm
/etc/regolith/styles/gruvbox
/etc/regolith/styles/gruvbox/root
/etc/regolith/styles/gruvbox/...
/etc/regolith/styles/lascaille/...
/etc/regolith/styles/ubuntu/...
/etc/regolith/styles/solarized-dark/...

After

• Load any Xresource files in /etc/regolith/Xresources.d, merge ~/.config/regolith/Xresources if exists.
• Determine path to configured look via Xresource key regolith.look.
• Load xresources from specified path. (/etc/regolith/Xresources may be empty or only define regolith.look)

File Layout

/etc/regolith/Xresources.d/regolith-look-minimal [vended by regolith-look-minimal]
/usr/share/regolith-look/minimal/... [vended by regolith-look-minimal]
/usr/share/regolith-look/gruvbox/... [vended by regolith-look-gruvbox]
/usr/share/regolith-look/lascaille/...
/usr/share/regolith-look/ubuntu/...
/usr/share/regolith-look/solarized-dark/...

Benefits Gained from Breaking Changes

• Less "magic" is needed for loading looks.
• Less package dependencies and unnecessary coupling.
• Look selection mechanism is an Xresource setting itself, reducing general variance.
• Minimal look will reduce the dependency closure such that a working Regolith configuration does not require specific fonts, themes, or other files.
• Looks can be staged anywhere on the filesystem (regolith.look defines a path to a Xresource file, not a directory child from a hard-coded root), allowing users to create and share looks without sudo or packaging knowledge.
• UI components not provided by default in Regolith can be added and supported via the Xresource facility.

Request for Comments

Please see this issue to provide feedback.