What to do about KColor?

[Ingo Klöcker]

On Monday 28 May 2007 14:19, Thomas Zander wrote:
> On Monday 28 May 2007 13:31:54 Ingo Klöcker wrote:
> > > On Monday 28 May 2007 03:31:54 Andreas Pakulat wrote:
> > >
> > >
> > > I, for one, think that its entirely natural that a color has an
> > > alpha channel and thus that if you blend two colors that it would
> > > be odd and unnatural to _also_ add an alpha to the argument list.
> > >
> > > For most KDE / Qt programmers an alpha channel is new in version
> > > 4, but if you come from a toolkit like Java this has existed for
> > > many years.  So, I can imagine that it takes a while to adjust to
> > > this change in concept.
> > >
> > > Lets see if people find it a bit odd.
> >
> > I find it more than a bit odd. I imagine most of us do not come
> > from Java.
>
> My point was that Qt was late in entering the game with the addition
> of an alpha channel to the color object.
> We have an alpha there now, and its certainly not an exception to the
> rule. So this is not a "if you come from [whatever].." this is more
> an "embrace change and use the new concepts to the fullest".

Alpha is pretty much irrelevant for the normal user of colors. Moreover, 
alpha is something a bit artifical since it doesn't occur in the real 
world. At least not in the same way as in computer graphics. OTOH, 
mixing colors is something that everybody should know from his or her 
childhood. Alpha is important for people doing computer graphics, but 
for most non-graphics application developer colors are opaque. I will 
rarely if ever change the alpha channel of a color and in fact I mostly 
want to ignore that the alpha channel does exist. I don't want to have 
to think about it. That's my view as an application developer whose 
most important need for color is the colors showing the validity of 
signed messages.

> I expect people to adjust to the new concepts over the duration of
> the KDE4 lifetime and when they do, then it becomes weird when there
> are two conflicting ways to set the blending amount.

Why conflicting? If I blend two colors with different alpha values a1 
and a2 then I'd expect to get the blended color with alpha value 
(a1+a2)/2 ( or (1-r) a1 + r a2 in the more general case ). Again, 
that's what I as email application developer (and maybe also as 
mathematician) would expect. I don't want to study color theory to 
understand what a certain method I want to use actually does. No, I 
want the method to do what I expect it to do. But I guess just as in 
application usability you'll get ten different expectations if you ask 
ten different people.

Whoever adds code to our core libraries should be aware of the fact that 
this functionality will be used by people who are not necessarily 
experts in the domain of this functionality. Functionality that does 
require more than a slight understanding of the matter and some common 
sense does IMO not belong into our core libraries but into some special 
purpose libraries, like say Pigment. So please keep the color related 
stuff in kdelibs dead simple and easily understandable for idiots like 
me. Thanks!

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070528/22e4e4c8/attachment.sig>