blend function urgently needed in kdelibs

[Matthew Woehlke]

Peter Penz wrote:
> On Tuesday 22 May 2007 16:37:29 Matthew Woehlke wrote:
>> Peter Penz wrote:
>>> Might not be "the" reason for "urgently", but we have already code for
>>> mixing colors in kdelibs/kfile/kurlbutton_p.h (protected method:
>>> KUrlButton::mixColors(...)) and Dolphin also requires it on other places
>>> (e. g. for having a slightly darker background on the inactive view, for
>>> creating mixed colors in the disk usage progress indication). I thought
>>> already about making a helper class inside Dolphin, but I would be glad
>>> if we would have a central place in kdelibs for such kind of things to
>>> prevent code duplication.
>> [snip] ... if you could give me specifics on what your requirements are
>> that would be helpful. [snip]
> <snip>
> 
> Great, thanks! I'm really happy that you brought in the suggestion that this 
> kind of functionality is needed.

Well, like I've said before, we already /have/ such functionality in 
about five different implementations in five different places. It's 
about time it was centralized. :-)

> My requirements for Dolphin are straight forward I think. Here they are:
> 
> - Mixing of 2 colors by 50 %

Easy: KColor::blend( firstColor, secondColor ). This is the main 
expected use case. :-)

> This could be done by alpha blending too, but this would be 
> more expensive...

I assume you mean by painting twice leveraging alpha functionality new 
in Qt4? (Just checking, because the alternate interpretation would be 
'what KColor::blend does'.)

> - Darkening colors: in the status bar of Dolphin the disk usage is shown. I 
> did not use a default progress bar for this, as it is visually too 
> distracting. So I render a very simple progress bar like you can see at 
> http://enzosworld.gmxhome.de/images/dolphin4_oxygen.png. But darkening with 
> QColor::darker() is very problematic, as it does not give enough contrast in 
> some cases (or too much) and also does not work if the color is already 
> black.

Right, QColor::darken is, as elsewhere mentioned, a bit "odd". You 
should be able to get much more consistent/reasonable results with 
KColor::darken... or KColor::lighter (they allow negative values, which 
means something like 'K times as "not-light" as the current color'; 
sometimes this is what you really want).

> I implemented a custom method for calculating a darker color, with a fallback 
> of having a lighter color if there is not enough contrast (see [1] at the end 
> of the mail, the code is in kdebase/apps/dolphin/statusbarspaceinfo.cpp). I'm 
> not sure whether it's worth to make those kind of method accessable in a 
> generic way, but maybe you get input from other application developers too.

As you guess, there are usability/style needs for this as well, 'get a 
contrasting color with a preference for making it darker' is a common 
need. I will probably write a darkContrast() function but I'm not sure 
if it will go in KColor or wherever gets the usability functions. Anyway 
  kcolor.luma() can still help out here by giving you the true 
gray-value of a color to decide if you want to darken or lighten.

In fact, darkContrast will probably look like this:

if ( c.luma() < amount )
   c.setLuma( c.luma() + amount );
else
   c.setLuma( c.luma() - amount );
return c;

This gives a more consistent contrast than "50% darker", although I may 
provide that option as well, with an 'at least <amount> contrast' 
option, which I think is most similar to your current code.

Does that sound good?

> Thanks again, I'll have a look at the SVN commits and will adapt Dolphin if 
> your code is committed :-)

Ok, feel free to ask if you want/need any help of course, I'm certainly 
happy to help with adoption. :-)

-- 
Matthew
"Nobody expects the traditional Bourne shell!"