blend function urgently needed in kdelibs

[Aaron J. Seigo]

On Monday 21 May 2007, Matthew Woehlke wrote:
> 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.)

i'll echo tzander's request for more readable API. 7 parameters is also a bit 
crazy, but perhaps that's unnavoidable for this. graphics programming 
sucks ;) but at least we can get proper parameter names; and BLEND_NORMAL 
should of course be NormalBlend or whatever, CS_RGB RgbColorSpace, etc...

what does the cmask (colour mask?) do?

this will all be easier with an actual implementation to comment on, of 
course.

> > 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. :-)

heh.. ok, well, the directories are topical and KColor's topic is certainly 
colors. =)

> > 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".

and-->

> > 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.

ok.. perhaps we can take this as the primary use case for this then. what sort 
of class do you see the usability colour palette stuff ending up in? would it 
also be KColor? or some other class? if the latter, then perhaps that should 
be where this goes vs having a class with one public method?

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

well, that's only half the equation. the other half is identifying apps 
that -will- use it, but only if it is in kdelibs. i think you've managed to 
do that.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070521/080b2d22/attachment.sig>