[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: changing KGraphicsUtils?
From: Michael Pyne <michael.pyne () kdemail ! net>
Date: 2007-05-31 22:47:17
Message-ID: 200705311847.17160.michael.pyne () kdemail ! net
[Download RAW message or body]
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
["signature.asc" (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic