[patch] KIconLoader: queryIcons() and queryIconsByContext()

[Michael Pyne]

On Friday 05 May 2006 01:04, Luke Sandell wrote:
> I found an annoying bug in KIconLoader. Normally, if you call loadIcon() or
> iconPath() with an extension in the icon name, removeIconExtension() will
> print a debug message. This behavior is fine. The problem is that
> queryIcons() and queryIconsByContext() call removeIconExtension() on every
> single file they find. This results in a long list of superfluous debug
> messages indicating that you are trying to load an icon by extension (which
> you're not).
>
> My solution was to add a boolean parameter to removeIconExtension()
> indicating whether or not it should be "quiet," e.g. not print debug
> messages when a file containing an extension is passed to it. It is set to
> true when called from queryIcons*() but false when called from loadIcon()
> and iconPath().

I like the idea, but I don't like the way it's implemented.  It's like adding 
a "no, I'm being an idiot on purpose" flag to a public API.  Not to mention I 
think we're trying to avoid bool parameters like this anyways in favor of 
more expressive enums.

My suggestion would be to factor out the functionality of 
removeIconExtension() into a protected/private internalRemoveIconExtension() 
or something like that (no debugging output), and then the 
internalRemoveIconExtension() would return whether there was an extension or 
not.  The public removeIconExtension() would simply use 
internalRemoveIconExtension() and output the debugging output if there were 
an extension.

We would then be able to transition the internal uses of removeIconExtension() 
in queryIcons() to the internalRemoveIconExtension(), and there would be no 
code duplication.

Any better ideas?  If you don't want to do it, Luke, I'll work on a patch 
sometime this week.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060505/4a8c98ae/attachment.sig>