wayprompt: use mkTarget

[panchoh]

Also, used the -hex variants of color specs for consistency and future-proofing.

The diff visualization is a bit messy, couldn’t be helped.

EDIT: ouch! I just saw that this was tackled in #1371 (although a search for wayprompt on the list of open pull requests doesn’t show it :-/)

Well, the good news is that since both implementations look identical (save for my changes on the second commit, namely adding the -hex suffix to color specs), and I’ve tested mine locally, this means one less thing to worry about.

Things done

• Tested locally
• Tested in testbed
• Commit message follows commit convention
• Fits style guide
• Respects license of any existing code used

Notify maintainers

CC: @awwpotato
maintainers: @nukdokplex @panchoh (adding myself feels funny :-)

[0xda157]

whats with the -hex? why don't the named colors use it?

[panchoh]

whats with the -hex? why don't the named colors use it?

Well, this is embarrasing…

When I first researched how to handle opacity, I took a hint from the module for fuzzel, which uses the -hex variants. I noticed that both -hex and non--hex variants of the colors had the same value (a 6-hex-digit string), but I took from the -hex suffix that the Stylix interface was offering a way to be more declarative with the intended encoding.

I scoured the git history, and found that the -hex variants appeared in several places, including some commits by @danth, like 4ac0094. So I assumed it was good form to use them.

So, in the PR #1257 I added commit ff01031, where I added the -hex form for the opacity, as a way to declare our intentions (and needs, since that’s the format that the Home Manager module expects), with the intention of maybe “upgrading” the rest of the values at a later date (this PR, as it turned out).

But after your comment, I went deeper and traced where these forms came from, and it seems that they were generated in-project, first in Python (f9daee0, look for "-hex"), later in Haskell (7b34be8), only to be ultimately replaced by SenchoPens/base16.nix (c235817). There I could see that the base-* values are actually aliases of their -hex counterparts. By the way, there is a pointer there to tinted-theming docs, where the spec for the required (-hex-*) forms is defined.

In conclusion, I see no good reason to use -hex forms here, since:
a) the SenchoPens/base16.nix provides the non--hex aliases as a convenience, hence they are not going away anytime soon, nor will they change its semantics/encoding.
b) the named colors don’t implement the -rgb-*|-dec-* discipline, so we would be introducing an ugly asymmetry here.

So, thanks for pointing it out, and sorry for the mouthful.

(I’ll suggest a change to drop the surviving -hex form on the opacity line in your current PR with Batch 3 of mkTarget updates #1371).

Closing now.

[danth]

I used to always use the -hex forms since they are part of the spec whereas the shortcuts are not, but as you say we're unlikely to stop using base16.nix any time soon so it doesn't particularly matter.