blend function urgently needed in kdelibs
mw_triad at users.sourceforge.net
Tue May 22 20:17:15 BST 2007
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]
> 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
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  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 );
c.setLuma( c.luma() - amount );
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. :-)
"Nobody expects the traditional Bourne shell!"
More information about the kde-core-devel