changing KGraphicsUtils?

Matthew Woehlke mw_triad at users.sourceforge.net
Thu May 31 16:41:04 BST 2007


Michael Pyne wrote:
> On Wednesday 30 May 2007, Matthew Woehlke wrote:
>> Michael Pyne wrote:
>> (...and naming it KColorUtils allows keeping calls shorter.
> 
> It's a possibility but don't do things just to keep calls shorter (by 3 
> characters no less). C++ provides the using keyword for that (and it can even 
> be function-local IIRC to avoid polluting the translation unit's namespace)

Agreed, though ironically this is also reason to keep (contents of) 
namespaces small :-).

>> But it's hard to say, really. How many methods do we want in a namespace?
> Good question.
> 
>>>>      QCOMPARE(blended, color2); // no transparacny.
>>> transparancy should be transparency.  Best to fix it now while the code
>>> is still being actively worked.
>> Zack/Thomas will have to take this one, I didn't look closely at what
>> the test is doing.
> 
> It's just a spelling error (in the comment, really a very minor nit) but it's 
> not worth fixing in its own commit so if it gets fixed while you're changing 
> the file anyways...

Oh, ok, I misunderstood. Sorry for that. :-)

>> There is isnan() but I want to say it's less portable than simply
>> testing that comparisons are always false :-).
> 
> As long as we're requiring gcc 3.3+ (3.4+?) then we should have isnan() 
> available on all platforms.  I mean, I inwardly groan when I see "available 
> since ISO C99" too but then it is eight years later, systems have to grow up 
> sometimes.

Well, the manpage says "CONFORMING TO: BSD 4.3" which is obviously a 
concern, although it also implies that C99 requires it. If no one has 
any comments to the contrary I'll use isnan(), we can always change it 
later if needed.

>>> Speaking of NaN, in the API documentation for the function you could
>>> probably mention that NaN results in returning c1 (or better yet, an
>>> undefined color) since you're testing for it anyways.
>> I would have thought that was obvious :-) ...but I can doc it (note: I
>> don't have access to my code handy ATM, so I'll have to do it tomorrow.)
> 
> On second thought if we document it here then people will expect us to 
> document it everywhere so it's probably better not to mention it.  GIGO 
> always applies, whether it's documented or not.

Right. :-)

>>> Also you use the register keyword in mix(). <snip>
>> Right. You can look at it as self-documenting, or I'm fine removing it.
> 
> I'd just say remove it.

Ok.

-- 
Matthew
"943. I am not Bjorn of Borg."
  -- from 975 things Mr. Welch can no longer do in an RPG
http://theglen.livejournal.com/16735.html





More information about the kde-core-devel mailing list