changing KGraphicsUtils?

Michael Pyne michael.pyne at kdemail.net
Thu May 31 04:06:01 BST 2007


On Wednesday 30 May 2007, Matthew Woehlke wrote:
> Michael Pyne wrote:
> > I think it's best to leave it as KGraphicsUtils (or similar)
> > because otherwise we artifically limit the namespace to dealing with
> > colors only, and who knows what we may have in there by KDE 4.4.

> (...and naming it KColorUtils allows keeping calls shorter. Like I said
> if we do non-color things I don't see a problem adding another namespace

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)

One of the things we're going for in the Qt4-ish API is descriptive names for 
methods, enum, etc., even when it involves more typing.

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

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

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

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

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/20070530/10300fb8/attachment.sig>


More information about the kde-core-devel mailing list