[$50] Remove all hex colors from widgets files [$50] about stylesheet

[danirabbit]

@h4ndshake the main goal here is to reduce the size of gtk-widgets-dark.css and make sure the two stylesheets don't get out of sync. The dark stylesheet inherits the light stylesheet, so anywhere we can have these overrides just be setting a variable, we're potentially reducing the possibility for breakage.

An example of this is in .window-frame where only the first box-shadow is different between the stylesheets, so instead of box-shadow: 0 0 0 1px alpha (#000, 0.75), it should be like box-shadow: 0 0 0 1px @window_frame_border,. That way if we decide to change the box-shadow size or direction on windows some day, we don't have to change it in both stylesheets.

[grinningtadpole]

@danrabbit

Is this issue still open? If so, I may have what you need...

I started test driving Elementary OS a week ago. The first thing I did was start working on a better dark theme -- the current one uses shades of gray that have heavy green and blue tints, which makes color sensitive work impossible. It also has bugs common to dark themes, like lightening the text shade for insensitive items, which looks fine in light themes but in dark themes makes the insensitive items look bold-faced.

To that end, I replaced every color reference in the gtk-widgets.css with a widget/style/state specific color reference. My gtk.css and gtk-dark.css both fully encapsulate all absolute and relative colors (shades, alpha, mix, lighten, darken). I've never built a gtk theme before, and I know very little css, so this was a necessary learning tool to make it easier to experiment.

In my gtk.css, there three sections: absolute colors, relative colors, and a color map to individual widgets/styles/states. The first section defines all absolute colors (e.g., black, white, base_color, error_color).

@define-color base_color #383e41;

Another section defines all the shades, alpha, mix, etc.

@define-color bg_color shade (@base_color, 0.96);
@define-color bg_highlight shade (@bg_color, 1.4);
@define-color bg_highlight_alpha_04 alpha(@bg_hightlight, 0.04);

Below that, a third section maps widget-specific color entries to a relative color, as shown below:

@define-color button_box_shadow_1 @bg_highlight_alpha_04;
@define-color button_box_shadow_2 @bg_highlight_alpha_45;
@define-color button_box_shadow_3 @bg_highlight_alpha_15;
@define-color button_box_shadow_4 @bg_highlight_alpha_15;

The naming scheme here relates to the primary object in the css selector. So button_xxx, would be a color defined in the default button state, button_focus_xxx would be a color defined in the button.css, with a state of button:focus or .button:focus, etc. Therefore, each color used in the widget.css files has a one-to-one mapping here.

If two widgets/styles/states use the same color, they will get their own local reference, but map to the same relative color. The button_box_shadow_4 demonstrates this. It uses the same color as button_box_shadow_3. Rather than use the same relative color in the gtk-widget.css, I gave them each a unique color reference. That way, if you ever decide that button_box_shadow_4 should use a different color shade than 3, you don't need to modify the gtk-widget.css, only the gtk.css.

Finally, in the widget css you'll find something like this:

button,
.button,
.titlebar .stack-switcher .button.image-button {
text-shadow: 0 1px @button_text_shadow_color;
icon-shadow: 0 1px @button_text_shadow_color;
background-image:
linear-gradient(
to bottom,
@button_grad_start,
@button_grad_stop_1 50%,
@button_grad_end
)
);
border: 1px solid @button_border_color;
border-radius: 2.5px;
box-shadow:
inset 0 0 0 1px @button_box_shadow_1,
inset 0 1px 0 0 @button_box_shadow_2,
inset 0 -1px 0 0 @button_box_shadow_3,
0 1px 0 0 @button_box_shadow_4;
color: @button_color;
transition: all 100ms ease-in;
}

The gtk-widget.css should never need to be edited for color information except a) if you want to add additional color stops to a gradient, or b) you need to separate two widgets/styles/states that are currently assigned the same style (e.g., you decide that ".button" and ".titlebar .stack-switcher .button.image-button" require different styles.

I found the gtk-widget.css to be a bit unwieldy when refactoring. My configuration uses the gtk-widget.css to load a bunch of smaller, individual css files from a directory named gtk-widgets. In that directory can be found base-state.css, button.css, etc. Each file corresponds to a section of the original gtk-widgets.css, and is loaded in the same order as the original gtk-widgets.css. If you need all the widgets in a single file, I would need to cat them together.

This was performed on the gtk-3.0 folder. I will be tweakiing whatever is necessary for gtk-3.22 (and eventually 3.90 or 4) as I plan to upgrade to gtk+4 (which requires 3.22, not 3.18).

I also have a different dark theme I can provide. It is a) more color neutral for those dealing with graphics b) darker for those of us working at night, and c) fixes the incorrect shading of insensitive items.

Let me know if this is useful for you. If so, I will upload the files.

[codygarver]

There is a bounty for this issue on Bountysource.

[danirabbit]

We don't get to change the selectors. Those are hardcoded into the toolkit

[megatux]

@grinningtadpole do you have a git repo with those changes to share?

[danirabbit]

Gonna close this because Greenfield should fix a lot of code duplication