<table><tr><td style="">sitter created this revision.<br />Restricted Application added a project: Frameworks.<br />Restricted Application added a subscriber: Frameworks.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D4254" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>the icon themes use SVG but do not want the same icon to be used for<br />
small resolutions as to not have high-detail icons at super small sizes so<br />
they become a mush of colors.<br />
on the other hand however they are SVG and thus scalable and so higher<br />
icon resolutions are not specifically made but rather expected to scale up.</p>

<p>the scaling up portion of the equation requires icon files to actually<br />
be available in a directory marked scalable. this is easy to get wrong and<br />
thus prevent higher resolutions from being available when doing a strict<br />
lookup as for example done by appstream.</p>

<p>e.g. if apps/64 is marked scalable but doesn't container a 'klipper' icon,<br />
if one then proceeds to strictly lookup a 192x192 version of 'klipper' one<br />
would come back empty handed.</p>

<p>to prevent this sort of issue from appearing in the future there are now<br />
two preliminary autotests to ensure icons are available in a scalable<br />
directory.</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">test_scalable asserts that all "fixed" icons (i.e. icons in a fixed size directory) are in fact also available as scalable (currently disregards size constraints involved)</li>
<li class="remarkup-list-item">test_scalableDuplicates asserts that each scalable icon only appears in one scalable directory. specifically if more than one scalable variant is available the icon theme spec does not specify that the closest match is used, but among scalable versions all are considered equal so the first wins. this is a problem if apps/48/klipper.svg and apps/32/klipper.svg exist and both are marked scalable but they have different visuals. in one application the 32 version might get used and in another the 48 version is used. this tests prevents this by enforcing the equality by means of not allowing multiple scalable variants (again, not taking size constraints into consideration)</li>
</ul></div></div><br /><div><strong>REPOSITORY</strong><div><div>R266 Breeze Icons</div></div></div><br /><div><strong>BRANCH</strong><div><div>master</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D4254" rel="noreferrer">https://phabricator.kde.org/D4254</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>autotests/CMakeLists.txt<br />
autotests/scalabletest.cpp</div></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="https://phabricator.kde.org/settings/panel/emailpreferences/" rel="noreferrer">https://phabricator.kde.org/settings/panel/emailpreferences/</a></div></div><br /><div><strong>To: </strong>sitter<br /><strong>Cc: </strong>Frameworks<br /></div>