I would not change the alpha at all. Instead, set alpha 255 in setPrivateRed: r green: g blue: b

It makes sense to be consistent. However blindly setting it to 255 is sometimes unexpected too:

Color transparent + Color transparent is assume to get Color transparent and not black.

Maybe for + we could add alphas, but for subtraction take the smallest alpha of two colors?��

Cheers,

Alex

On Sat, Mar 21, 2015 at 12:32 AM, Nicolai Hess <nicolaihess@web.de> wrote:

2015-03-21 0:19 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>:

Hi,

I played with colors and found out, that��arithmetical��operations with colors are completely broken.

https://pharo.fogbugz.com/f/cases/15188/Color-ariphmetical-operations-are-broken

Result is not a valid Color - just garbage. It happens because alpha is not being initialized and stays nil. It seems that operation were implemented before alpha support was added. So I propose the following solution:

Color red - Color red = Color transparent

(Color white alpha: 1) - ��(Color white alpha: 0.5) = (Color white alpha: 0.5)

R,G,B are subtracted as before. Alpha channels are subtracted too.

Color red + Color blue =��Color magenta

Color red + Color transparent =��Color red

(Color white alpha: 0.5) + (Color white alpha: 0.5) = (Color white alpha: 1)��

��R,G,B are added as before. Alpha channels are added too.

Multiplication and division by number doesn't change alpha channel.

Cheers,

Alex

I would not change the alpha at all. Instead, set alpha 255 in setPrivateRed: r green: g blue: b