KColor is coming this Monday...

[Andreas Pakulat]

On 25.05.07 23:04:24, Matt Rogers wrote:
> On Friday 25 May 2007 21:13, Adam Treat wrote:
> > On Friday 25 May 2007, Michael Pyne wrote:
> > > But I guess the question for kdelibs is, do applications need a blend()
> > > or do applications need the full-blown capabilities of KColor?  And if we
> > > put
> >
> > From what I can tell, the only application that has spoken up as a consumer
> > of this class is KDevelop which is not even targeting KDE4.0.  Also, it is
> > not clear if KDevelop would be just as happy using the QColor blend method
> > that Zack pointed out.
> >
> > Andreas, can you tell us if Zack's version of QColor blend is good enough
> > for KDevelop's needs?
> >
> > This whole thread is unnecessary if no applications need such functionality
> > in KDE4.0
> >
> Considering I don't even know what KDevelop needs blend functionality for.

As an example: Provide a color that indicates a warning in output.
Currently the outputview uses highlight() and linkVisited() from the
palette, both of these are not really right to use for error and
warning. If the usability code is added to KDE we'd get at least a
proper color for error and for warning I think it would be best to blend
error with the background color (or maybe just lighten it) to get a
proper warning color.

Also there are a few places in KDevelop3 where blend is used, because
the colors provided by the palette are too few sometimes and we
shouldn't hard-code any colors.

Also I can't tell anybody wether Zack's or Matthews stuff is better,
because I have absolutely no experience in this field (I don't even see
much difference in the example jpg that Zack posted).

As far as usage goes, IIRC the dolphin developers want to use blend()
too and there are a few other blend() methods in KDE's sources which
would be obsoleted by a blend() in kdelibs.

Andreas

-- 
Don't relax!  It's only your tension that's holding you together.