This is the same issue as #120 but I am experiencing it on Arch Linux (5.1.12-arch1-1-ARCH) using pywal 3.3.0 and urxvt.
As far as I can tell, the problem seems to be that the alpha property used in the templates always uses util.Color.alpha_num. This value is only correct when the -a
switch is initially passed to set the transparency. When -R is passed the default value of 100 is used and the colors.Xresources file is generated incorrectly beforre xrdb -merge is called.
One way to fix this would be to set util.Color.alpha to the value from the colorscheme file when -a is not passed.
As mentioned in pull request #146, it could also be fixed by removing the -a flag entirely and having the transparency defined in a user template. This makes the most sense to me, because I don't really see transparency as part of the colorscheme itself but more of an application specific setting. If I switch backgrounds, I don't need my terminal transparency to change. Furthermore it would simplify the codebase a bit.
If we do want to keep handling transparency in pywal, we should add it to the filenames of the colorschemes so that two themes generated from the same image with different transparency values can coexist.
If I could get some feedback on which solution would be preferred, I would be glad to implement the fix.
hnrq
commented
2 years ago
This is the same issue as #120 but I am experiencing it on Arch Linux (5.1.12-arch1-1-ARCH) using pywal 3.3.0 and urxvt.
As far as I can tell, the problem seems to be that the alpha property used in the templates always uses
util.Color.alpha_num. This value is only correct when the -a switch is initially passed to set the transparency. When-Ris passed the default value of100is used and thecolors.Xresourcesfile is generated incorrectly beforrexrdb -mergeis called.One way to fix this would be to set
util.Color.alphato the value from the colorscheme file when-ais not passed.As mentioned in pull request #146, it could also be fixed by removing the
-aflag entirely and having the transparency defined in a user template. This makes the most sense to me, because I don't really see transparency as part of the colorscheme itself but more of an application specific setting. If I switch backgrounds, I don't need my terminal transparency to change. Furthermore it would simplify the codebase a bit.If we do want to keep handling transparency in pywal, we should add it to the filenames of the colorschemes so that two themes generated from the same image with different transparency values can coexist.
If I could get some feedback on which solution would be preferred, I would be glad to implement the fix.