Extend XRDB support to BAR_ALPHA patch

[UtkarshVerma]

This PR makes the bar alpha configurable through XRDB.

[bakkeby]

I see how this would work, but in practice it would make your Xresources file even more unmanageable I'd think.

I was thinking that in your Xresources file you'd have colour values such as #ba9933 and #ba993380, where the latter is an RGBA colour code specifying the alpha value as 0x80.

The thing that would need to change on dwm's side is for the xrdb (or colour handling in drw.c) to detect whether the colour value is in RGB or RGBA format and handle that accordingly. In principle this way one could also get rid of the alphas array altogether (unless it is convenient somehow).

Might make sense after #263.

[UtkarshVerma]

Regarding Xresources file, it is pretty straightforward if we use wildcards, this is what I have currently in my pywal template:

Also, RGBA implementation would be really cool. One way I think we can implement it is using unions:

union color {
    uint8_t r, g, b
    #if BAR_ALPHA_PATCH
    ,a
    #endif
    ;
};

In my opinion, alphas array should be removed as it doesn't make sense to split a single scheme to multiple arrays.

[bakkeby]

You are right the alphas using wildcards in the Xresources file would make it fairly simple in that respect.

[bakkeby]

@UtkarshVerma could you have a look / play around with this branch of dwm-flexipatch?
https://github.com/bakkeby/dwm-flexipatch/tree/vertigo

It has a few proof-of-concept changes incorporating these alpha resources as well as support for RGBA colours.

[UtkarshVerma]

@UtkarshVerma could you have a look / play around with this branch of dwm-flexipatch?
https://github.com/bakkeby/dwm-flexipatch/tree/vertigo

It has a few proof-of-concept changes incorporating these alpha resources as well as support for RGBA colours.

Sure. The new commits look good. Will give them a go.

[UtkarshVerma]

Has there been any update on the vertigo changes? They look pretty nice from development point of view. I would love to help get it merged to main.

If not, could you please let me know what changes I should make to this PR?

[bakkeby]

I don't think the vertigo changes are something that would ever be merged in. It is more of a showcase for how certain things could be handled. There wasn't much interest tbh. I have expanded on most of those ideas in my dusk build.

On the topic of alpha values I have yet to meet someone who actually use different alphas for different colour schemes. The main incentive, I think, is if someone wants to have a part of the bar that is fully transparent.

I suppose that it kind of made sense for the original alpha patch to add opacity levels per colour scheme (there were just two colour schemes mind you).

In practice though I think that it would overall have been better to just have one default value for the opacity and if there is a need to have a separate opacity for a specific colour then one could override that in another way (for example by using RGBA colours).

That you can change the alpha for the border colour I figure could be useful if you do not use gaps, but use a transparent border for unfocused windows.

That you can change the alpha for the foreground colour, hmm, maybe in some special contexts like where the foreground and background colours are inverted? I have never been able to successfully apply transparency for text.

As for this PR, if we decide to go for it like this, then it is probably fine as-is. I would probably want to refactor xrdb.c to not use silly macros and to do it all a bit more cleanly.