blend function urgently needed in kdelibs
mw_triad at users.sourceforge.net
Mon May 21 22:03:03 BST 2007
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
> 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
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
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. :-)
When in doubt, duct tape!
More information about the kde-core-devel