Add support for special theme for unfocused outputs

[bpeetz]

I use multiple outputs, and as such often need to remember which output is currently focused.

Fortunately, river tells us which output is currently in focus.
Therefore, we can track this in river's info provider, and then use this value to decide which theme to use when drawing the bar.

For users that do not need or want this extra differentiation, setting the [theme.palette] values, will result in the previous behaviour as the [theme.unfocused_palette] will inherit them if not set.

By default, that is with [theme.palette] unset, we will use a darker white for the unfocused_palette's foreground, to signify that this output is unfocused.

I am not familiar enough with niri or hyprland to know if they can support something like this too.
As such, both of their information providers do not override the default is_output_focused method.

In the future moving even more values to the themes might be a viable approach (i.e., the font), but with the current values most workflows should be possible (e.g., hiding inactive tags on the unfocused output, whilst showing them on the focused one or simply setting darker colours).

[MaxVerevkin]

I guess another approach (more flexible) is to allow separate theming of unfocused outputs? I think I would prefer that.

[bpeetz]

So a additional unfocused_output flag on a Tag, that is orthogonal to the normal tag modes?
I assume, that this would mean having unfocused_output variants for the tag_{,focused,inactive,urgent}_{fg,bg} config values?

[MaxVerevkin]

So a additional unfocused_output flag on a Tag, that is orthogonal to the normal tag modes?

Probably a new function WmInfoProvider::get_output_focused(&self, output: &Output) -> bool.

I assume, that this would mean having unfocused_output variants for the tag_{,focused,inactive,urgent}_{fg,bg} config values?

Yep. In config this may look like

[theme.pallet]
background = "#282828ff"
color = "#ffffffff"
separator = "#9a8a62ff"
tag_fg = "#d79921ff"
tag_bg = "#282828ff"
tag_focused_fg = "#1d2021ff"
tag_focused_bg = "#689d68ff"
tag_urgent_fg = "#282828ff"
tag_urgent_bg = "#cc241dff"
tag_inactive_fg = "#d79921ff"
tag_inactive_bg = "#282828ff"
[theme.unfocused_output]
tag_focused_fg = "..."
tag_focused_bg = "..."

struct Config {
    theme: Theme,
    // ...
}

struct Theme {
    pallet: Pallet,
    unfocused_output: Pallet, // inherits from `pallet`
}

struct Pallet {
    background: Option<String>,
    color: Option<String>,
    // ...
}

[bpeetz]

Do you see another way to implement inheriting without having to duplicate the Pallete structure? Having options in the main structure itself seemed rather unwieldy for me

[MaxVerevkin]

Do you see another way to implement inheriting without having to duplicate the Pallete structure? Having options in the main structure itself seemed rather unwieldy for me

The current implementation looks good to me :)

[MaxVerevkin]

The readme needs to be updated.

[MaxVerevkin]

Also I would prefer to somehow keep the old configuration working for now and not break the existing configs.

[bpeetz]

As mentioned in the commit message, I'm not so sure that the g_warning! macro is actually the correct way to issue a warning, but eprintln! seem to “weak” for this situation.

(Oh, CI seems to be dead?)