<div dir="ltr"><div><div><div><div><div><div><br><div class="gmail_extra"><br><div class="gmail_quote">2016-04-27 2:26 GMT+02:00 Aleix Pol <span dir="ltr"><<a href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
As assessed lately, one penalty we have when starting an application<br>
is the icons look-up. It's not really Breeze's fault, the intersection<br>
of the standard we're using and how we're using it makes the situation<br>
slightly complex, hence simplifying it would improve the situation<br>
already.<br></blockquote><div>First I want to say that most 3rd party icon sets had the same issues,<br></div><div>cause they are available as svg files in same (not all) icon sizes.<br><br></div><div>I personaly prefere svg files cause that's the source and you can style them<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To get some context, the problem is that whenever we request an icon,<br>
what we do is go through all the provided directories hoping we'll<br>
find it.<br>
<br>
Now I'm mentioning breeze because on one hand, it's really awesome how<br>
we're using scalable icons directly but on the other hand we could<br>
look into leveraging it better. Here's some ideas, I'd especially like<br>
the icon designers' opinions so we can find the best situation.<br>
<br>
* There's some sizes that we can probably trim right away. Are icons<br>
in the 12 and 16 directory substantially different? Or 22 and 24? I've<br>
checked and pruning these would get us about 5% of failed accesses<br>
back.<br></blockquote><div><br></div><div>About icon sizes we don't offer all sizes. We ordinary offer the main size<br></div><div>e.g. application icons are available in 48px which was used for the dash<br><br></div><div>the action, mimetype and places icons are available in different sizes,<br></div><div>cause svg files have NO scaling problem but breeze has a scaling issue.<br></div><div>if you scall a 22px icon with 1px thin "lines" to 16px the line is blured.<br><br></div><div>there is only ONE dictionary where you can "merge" the icons<br></div><div>action/22 and action/24 are the same icons where 24 has a 1px bigger margin.<br></div><div>BUT 24 px icons are ONLY for GTK apps (Inkscape, Firefox, ...) That's also <br></div><div>the reason why not all 24px icons are needed in 22px, ...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Furthermore, I see there's some icons that aren't on every size (for<br>
example, vcs-added is only in 16 but not in 8 or 22). All in all,<br>
feels like it could be specifying broader categories, especially<br>
considering the scalable nature, such as emblems/small, emblems/big.<br>
<br></blockquote><div>emblem icons were made ONLY for the default size as I don't found an issue<br></div><div>I don't see the need to have all in all sizes. Uri was really strict with sizes<br></div><div>Icon's are only needed in an specific size if it was needed anywhere.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Last, slightly unrelated, there's a risk when the icon differs<br>
greatly (e.g. system-help) from a size to another we'll end up with<br>
unpredictable UI's, maybe it would be possible to rename them to<br>
reflect this.<br></blockquote><div> </div><div>That's a bug, but yes we have issues with monochrome icons and colored ones<br></div><div>cause some icons are needed in small size as monochrome and in big size colored<br></div><div>There the big issue is 32px icons in size cause I'm not sure if they should be<br></div><div>monochrome or colored. In addition one icon in different colores is a problem.<br></div><div>Should be solved in the codebase of the app.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Do you think there's any possibility we could improve there?<br>
<br>
Thanks a lot!<br>
<span class="HOEnZb"><font color="#888888">Aleix<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">As I wrote in my blog post I cleaned the svg files <br>e.g. the widget explorer icons are now really small and should be way faster to render<br><br></div><div class="gmail_extra">As a app developer you work on cpp, h files <br>when you are finished you compile your stuff to fit your platforms and to improve the speed<br></div><div class="gmail_extra"><br>It's the same here, Icons were made (not only for breeze) with svg files, </div>I don't want to include png files (in all sizes) to the source, cause than it is not possible to <br></div>style icons according the color scheme.<br><br></div>I thought it worked that way that you select an icon set and the system generate png files<br></div>with the defined color scheme. If the user change the color scheme or the icon set,<br></div>the temp png files were generated again. This icon were used from the applications.<br><br></div>cheers<br></div>Andreas Kainz<br></div>