Support changing colors and font through the X resource database system

[notuxic]

This PR adds support for changing the hardcoded colors and font using the X resource database system.

While I appreciate the simplicity of i3lock and its stance on feature-creep, I do find the state of its hardcoded styling somewhat sub-optimal for various reasons. For example, the color scheme may provide bad user experience for people with vision deficiencies such as color blindness or low contrast sensitivity. But also an interest in adapting the styling to fit in with the rest of ones system for a visually consistent experience should not be disregarded entirely.

Contrary to previous attempts at getting such a feature into i3lock, this implementation uses the X resource database system. This way no additional command-line arguments are introduced. XRDB is already used in i3lock to query the DPI setting, and using it to set styling preferences is also in line with i3wm, which also has a system allowing something similar.

I hope that this implementation manages to finally introduce a basic degree of styling, in a manner satisfying to both users and i3lock' maintainers. I'd ask to take this PR into consideration, not disregarding it immediately, even though it falls under personal opinion, as IMO a hardcoded styling is also opinionated, if not even more so ;).

PS: For reference, skimming through the issues and PRs, this should also provide a solution for: #34, #94, #105, #197, #271

[stapelberg]

Thanks for your PR!

I appreciate the rationale, and re-using the x resource system is definitely a better choice than introducing a bespoke config file or adding lots of command-line switches.

That said, I still don’t think customization at that level is something that i3lock should offer—mostly for scope creep and maintenance effort reasons, but also because accepting more user input than strictly necessary into such a security-sensitive program is not something I’m comfortable with.

Perhaps the folks at https://github.com/Raymo111/i3lock-color would be interested in your contribution?

[Airblader]

For example, the color scheme may provide bad user experience for people with vision deficiencies such as color blindness or low contrast sensitivity.

Just to elaborate here: if this is really the case I think it'd be OK to change the current colors to improve the experience for these users.

[stapelberg]

Just to elaborate here: if this is really the case I think it'd be OK to change the current colors to improve the experience for these users.

Yes, if there are subtle adjustments we can make to improve the contrast ratio, for example, we can definitely talk about that :)

[notuxic]

Just to elaborate here: if this is really the case I think it'd be OK to change the current colors to improve the experience for these users.

Yes, if there are subtle adjustments we can make to improve the contrast ratio, for example, we can definitely talk about that :)

Problem here is, that different deficiencies have different requirements, so finding a one-size-fits-all solution is next to impossible, especially if you want to retain a intuitive color scheme for the remaining users.

That said, I still don’t think customization at that level is something that i3lock should offer—mostly for scope creep and maintenance effort reasons, but also because accepting more user input than strictly necessary into such a security-sensitive program is not something I’m comfortable with.

I understand this, and this rational is also the reasons I'd prefer to use i3lock over eg. i3lock-color. I do however not think that this addition would necessary contribute to feature-creep, as it does not really add something new, but rather allows for changing something that I think shouldn't be hardcoded as a permanent solution in the first place. Regarding maintenance, one option could be to remove some of the customization options, such as font-changing and simplifying the number of color options somewhat. The remaining modifications would be rather simple, so I doubt that they would noticeably contribute to maintenance effort or open up the application to potential security problems.