Color alpha

[Alittlemurkling]

I could be doing something wrong when I build, but this branch appears to only read RRGGBB colors instead of RRGGBBAA like the master.

I'm on Arch Linux x86_64, Linux 3.16.4-1-ARCH, and built with gcc 4.9.1 20140903.

Otherwise, I would like to give my deepest thanks for this port— I have been missing my xft fonts in my statusbar.

[krypt-n]

Could you give an example of what works in the master but does not in xft-port?
If I am not horribly wrong, master uses #AARRGGBB. There is one change regarding this in xft-port, it assumes a = 255 if there is just #RRGGBB or AA = 00.

[krypt-n]

Okay, I found a difference between master and xft-port when using a != 255, a != 0 and a compositor

[Alittlemurkling]

Ah, putting the alpha last was a typo. I'm used to that order from gtk.

If I have time to hack on it this weekend, I may be sending you a pull request.

[cjk]

Having the same problem here. I'm using a compositor but even though all my colors start with 'FF' they still come out wrong.

[krypt-n]

What compositor and parameters (for bar) are you using? I can't reproduce your problem on my setup.

[cjk]

I'm using compton and call bar like this:
bar-aint-recursive -g x24 -f -misc-fixed-*-*-*-*-*-*-*-*-*-*-iso10646-*,Bitstream Vera Sans Mono-10,Arial-10 -F #FFA3A6AB -B #FF34322E

(font-names are quoted unlike seen here)

When I use the X11-core font only or as the first parameter, all is fine, colors are normal. But everything rendered with an xft-font (like unicode-characters) become red-dish. If I put an xft-font first, the whole bar is rendered in a whole different foreground-color (red, in my case) though I never specified it.

[krypt-n]

Thank you for reporting that issue. I was just snprintf'ing the color into a string for xft and that caused alpha to be interpreted as red if alpha != 0. The latest commits should fix that.

[cjk]

That was fast! :)

I rebuild using the xft-port branch and everything works as expected now - no more red-only text.

Thanks a lot!