Problem with "Rotate number of new messages for each account"

[tatoo_ar]

Hi! After installing the new Pop Peeper v4.3 and the update to Skin Notifier to v4.3 also, I'm having a bothering side effect in the PP's tray icon. I have checked the "Rotate number of new messages for each account" under Options/Tray Icon, and previously the icons were colored circles with a white number inside it. But after the update the numbers within the circle became dark, and now it's very difficult to distinguish them. What can I do to recover the white numbers? Should I downgrade the Skin Notifier? Where can I download it? Thanks in advance.

[Jeff]

This is currently under review. Can you tell me the RGB (Red/Green/Blue) values for the specific colors that you have a problem with? While you're getting the values, you can also make a slight adjustment to them to fix the problem:
1) Edit the account
2) Click the Color button on the top-right
3) Press the "Other..." button
4) You'll find the Red/Green/Blue values on the bottom-right of the color window (let me know what they are)
5) To the left of the RGB values are Hue / Sat(uration) / Lum(inence) -- adjust the Lum (Light) value down. e.g. try a value of 115 (presumably, that's not too far off [e.g. 5-10] from its current value)

The way it works is that a dark background color will use white text, and a light color background will use black text; so by forcing the background color to be a little darker, you'll get the white text. Right now, I know that the solid blue color (rgb = 0/0/255; as would solid red [255/0/0] and green [0/255/0]) has this problem, but if you have any other colors that you use that cause this problem, let me know what those colors are so that they can be included in testing.

btw, this is unrelated to the Skin Notifier.

[Jeff]

btw, there's probably a graphics designer reading this and shaking their head right now...

[Jeff]

Ok, good news. I spent the last hour finding and implementing a formula that has much better results (after a tiny tweak to the formula I found). So, if you have those RGB values, let me know and I'll test them with the new formula.

As of right now, I don't know if this one issue is worth releasing an update for, so if anybody else has this issue, let me know! and we'll wait and see.


I thought that the formula was kind of interesting so I thought I'd share it. If you don't care about the details, stop reading!


As you may know, every color on your monitor is a composite of 3 colors (red, green, blue) where each separate RGB value ranges between 0-255.
There is a formula that converts values between RGB and HSL, and vice-versa.

It turns out, the "correct" formula to use does not use the "Light" of HSL as I would have expected. This is rather evident when you consider:
Blue (0/0/255)
and
Yellow (255/255/0)
both have a "light" value of 128 (not shown, just trust me); but the preferred colors would be
white on blue
black on yellow
So: not the same text color even though the "light" colors are the same.

The new formula basically says:
- assume that the text color will be white
- the more "green" that's in the color, the more likely the text color will need to be black
- the amount of "blue" in the color hardly makes a difference (it takes 5x the amount of blue to match green)
- the amount of "red" is in-between (it takes 2x the amount of red to match green)

So, if we look back at the previous 2 examples:
Blue (0/0/255) -- as we know, blue hardly makes a difference, so the text color will be white
Yellow (255/255/0) -- Lots of green and lots of red: the text color will be black


Anyway, *I* thought it was interesting... I may be the only one

[tatoo_ar]

Thanks Jeff. Yes, I was using solid blue (0/0/255). Now I changed the Lum value from 120 to 110, so the RGB values are now 0/0/234. I will try it out, at least until you implement the new formula you've found.

Thanks for the quick attention.

[Jeff]

Ok, a test version is now available which implements the new algorithm. Please download it from the following page and let me know if this fixes the problem for you (it should, I have specifically re-tested solid blue, #0000FF, and it does display in a much more legible white text color):

http://www.esumsoft.com/pop-peeper-beta/

[Jeff]

Also, a little bit more information on how this issue came to be:

When I was originally testing the algorithm in v4.3 (final), I used the default colors that POP Peeper uses when creating new accounts. There is no solid blue color; the closest color match is 0/0/224 -- which is dark enough to use white text color.

But when people kept telling me that there were issues with this in v4.3 (and a couple of people specifically mentioned blue) I took a closer look. It turns out, the color scheme went through a minor cosmetic change in v4.1 that I had forgotten about*; prior to that (e.g. PP v1.0 to v4.0), one of the default colors was problematic solid blue (0/0/255 or #0000FF). So -- that's how so many people have the solid-blue color and how I managed to miss it in testing


* - according to my internal notes, the reason for this change in v4.1 was:
"some slight modifications to default account colors so that they're darker and easier to read against white background"

[tatoo_ar]

Downloaded the beta version and installed it. Also reverted the color scheme back to solid blue in my main account. Worked as expected, white numbers on blue background. Thanks!

By the way, I'm using Pop Peeper since August 2003, when SSL was mandatory to retrieve messages in some servers and the good old "Magic Mail Monitor" I was using could not handle it. Not sure what PP version was, but I think it was 2.x.

[Jeff]

Glad POP Peeper still suits your needs!

According to the version history, v2.2.9 was released in June 2003. I spit out new versions like a pez dispenser back then