Review Request 127632: Prioritize correct extension per theme

[Nick Shaforostoff]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127632/#review94759
-----------------------------------------------------------


Ship it!




i think adhering spec here is not very important.

we can adopt this change now, mention this somewhere in docs (print a qWarning saying that the checking order has changed?), and introduce X-KDE-Extensions later (which would only require a slght adjustment of iconPathByName() method).

- Nick Shaforostoff


On April 11, 2016, 11:17 p.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127632/
> -----------------------------------------------------------
> 
> (Updated April 11, 2016, 11:17 p.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> -------
> 
> Usually themes will have 1 kind of extension (2 tops) it doesn't make sense to bindly use an extensions vector that is statically defined.
> 
> Prioritizes the extensions that work, so it will find the icons sooner.
> 
> 
> Diffs
> -----
> 
>   src/kiconloader.cpp 37528ad 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp e7e003b 
> 
> Diff: https://git.reviewboard.kde.org/r/127632/diff/
> 
> 
> Testing
> -------
> 
> Builds and tests still pass.
> Also reducess faulty disk accesses to its 45%. Note that by this metric, it's almost as good as the RR #127236, but with a much smaller memory impact, since we're not caching all the icon names (which was specially bad as it was per-process).
> ```
> $ strace kwrite |& grep ENOENT | wc -l
> 4699
> $ strace kwrite |& grep ENOENT | wc -l
> 2119
> ```
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160422/c86fe353/attachment.html>