changing KGraphicsUtils?

[Michael Pyne]

On Thursday 31 May 2007, Thomas Zander wrote:
> I have some issues with your patch
> * we now have two similar methods that people have to choose from. We
> explicitly made the blendColors to be good enough for everyone to use by
> making it a very simple API and good enough implementation.
> Adding a second next to that counters this result gained and therefor
> should be avoided.
>
> * We are still / again doing design by committee. We really need usages of
> the API so we have a set of proper use cases.  I would (re) request that
> we wait for the codebase to actually gain those before we make decisions
> on how the method should react.  There just are too many different
> opinions on what is best.

I thought we already had input from developers saying they needed a function 
like mixColors()?  In the end this is all still about blending but the 
current implementation of blendColors() is apparently still lacking. :)

I agree that we should choose one but since we already have code that cannot 
be implemented using blendColors() then perhaps we should consider this a 
second try and merge the two methods if possible.

> * Your patch leaves in code of me/zack but you remove the copyright lines.
> That's [censored], please don't.

The copyright was changed to list what function exactly was contributed but 
was not removed.

> * Your patch has a comment like this one;
>
> >+   // This isn't exactly fast :-(
>
> It doesn't help anyone to state your opinion on it with a sad smiley and
> it certainly doesn't add any value to the method.  Its just being nasty
> at your fellow programmers. Please don't do that.

It adds value by identifying the method for future optimization efforts 
(although profiling is still the best way).  And although I agree comments in 
kdelibs should certainly be more professional, do we really need to ban 
frownies?  If so we need to update the techbase page for the kdelibs coding 
style. :)

> >  I would like to commit Monday if
> > there are no (unresolved) issues at that time.
>
> As I suggested elsewhere the haste seems unneeded and unwanted as we need
> to be using this code and not talking on mailinglists for another week,
> painting the next bikeshed a semi-transparant color.

Well there are already applications using this code (KDevelop and the Ion 
widget style, Plastik uses similar code from what I understand) so we've 
already done that.  Monday is the typical commit day for new kdelibs features 
I thought (unless of course there is still ongoing discussion).

> So, I would really like it if we made sure we got some use cases and then
> we can see if things like having an alpha in the blended color is needed,
> wheather RGB blending is good enough and what method signature is best so
> we don't end up with 2 methods if we can do with one good one.

Agreed.

> I know you really want to move and be active, but please give others the
> time they need, thanks! :)

Well since adding a new class shouldn't be binary incompatible perhaps we can 
allow it in next Thursday (7-June) if everything is resolved?  We shouldn't 
drag out discussion longer than necessary.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070531/107622bf/attachment.sig>