blend function urgently needed in kdelibs

[Matthew Woehlke]

Aaron J. Seigo wrote:
> On Monday 21 May 2007, Matthew Woehlke wrote:
>> Matthew Woehlke wrote:
>>> kdelibs desperately needs a color blending function. I am volunteering
>>> (yet again) to provide one that looks like this:
>>>
>>> KColor blend(const KColor& c1, const KColor& c2,
>>>              double k = 0.5, double r = 0.5, SPEC cs = CS_RGB,
>>>              int flags = BLEND_NORMAL, int cmask = 0x0000FFFF);
>>>
>>> Can someone PLEASE suggest where I can put such a thing? (Due to lack of
>>> prior response, if I don't hear back by next Monday I'm going to /pick/
>>> somewhere and people can bitch about it.)
>> In fact, unless someone says otherwise it's going in
>> kdeui/kernel/kcolor.* on 5/28.
> 
> why would it go into kernel? have you actually looked at what's in 
> kdeui/kernel? it's stuff related to core application structure, e.g. 
> kapplication. kdeui/colors is for all things color related.

Yes, and I looked in kdeui/color, which was all color /picking/ stuff, 
which is why I picked kernel. :-)

> kdefx is another option, but i'd really like to see kdefx slowly melt away to 
> be honest. if kcolor is meant as a short term solution, then kdefx can be a 
> place for it.

Mmm... yes and no. It's partly needed because TT never (AFAIK) 
implemented blend() or HSY (or even HSV) colors, but in kdelibs it is 
more flexible than QColor, so probably blend() will be around until KDE5 
at least.

> if you/we plan for it to become a broader set of kde solutions 
> including such things as the openusability recommendations, then a more
> permanent and prominent home for it should be made, e.g. kdeui/colors. this 
> is particularly true if many apps will end up using it.

Yes and no. Basically KColor supports blend() and that's it. That's 
/needed/ for some usability concerns, but the major usability stuff is 
"higher level".

At minimum, the objective is that no apps will ever implement their own 
blend() again. :-)

> now, that said.. why does this need to go into kdelibs so urgently at this 
> point?

Because June 1 is approaching and *I've been asking for it for months*.

> which apps or classes will be using it?

KDevelop probably. It is needed for some usability concerns (and if 
those aren't addressed, KDevelop /will/ need it). Styles probably want 
it (plastik should be converted, Ion will use it if/when I ever get it 
ported...). Oh, and - although unlike the other examples I'm not 
familiar with the specific code - I think kate will/can use it as well. 
That makes two users /in kdelibs/, right now, with more on the way for 
4.1 :-), and I'd be surprised if there aren't other potential users out 
there (kdegames and kdeedu come to mind).

> those are more important to 
> answer than "so where am i going to put it, because i am going to put it in!" 
> the answer may lead us to alternative places for this class for 4.0 where it 
> can mature and prove itself with the idea of moving it to kdelibs for 4.1

I'm mainly concerned that if the usability stuff doesn't happen *now* it 
won't happen until KDE5, as it isn't clear if there will be BC issues. 
And it /won't/ happen without blend() in kdelibs.

Also it's a blending function :-). If it can do basic blends that's what 
most users need; I expect it to grow as needed.

...And for the usual "if it isn't in 4.0 no one will use it" reason. :-)

-- 
Matthew
When in doubt, duct tape!