<div dir="ltr"><div>That's great Ken, I love your work.</div><div><br></div><div>However I already work on a MR to use the highlight color for the places icon see</div><div><a href="https://invent.kde.org/frameworks/breeze-icons/-/merge_requests/141">https://invent.kde.org/frameworks/breeze-icons/-/merge_requests/141</a></div><div><br></div><div>Let me know if I should finalize the MR or you will jump in.</div><div><br></div><div>5 Years after my last icon work for breeze I come back <br></div><div>and 2 weeks later the awesome Ken. That's fantastic.</div><div><br></div><div>cheers</div><div>Andreas_K<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 18. Okt. 2021 um 21:30 Uhr schrieb Noah Davis <<a href="mailto:noahadvs@gmail.com">noahadvs@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Ken, this sounds like a really cool idea and I'd be interested in<br>
seeing what you have in mind.<br>
<br>
On Mon, Oct 18, 2021 at 12:50 PM Ken Vermette <<a href="mailto:vermette@gmail.com" target="_blank">vermette@gmail.com</a>> wrote:<br>
><br>
> Also relevant: [Breeze] [Bug 443288] New: Custom folder icons<br>
><br>
> Hey all;<br>
><br>
> There's been quite a bit of interest in having colour scheme<br>
> responsive full-colour icons, especially with the accent-colour being<br>
> much more accessible. In addition the Breeze "Blue Ocean" refresh has<br>
> been coming along very nicely (congratulations to everyone behind it!)<br>
><br>
> I would like to gauge any interest in allowing me to do a larger<br>
> refresh on the full-colour icons in Breeze. This would include<br>
> "modernization" to the current trends, adjustments to the style spec,<br>
> writing up new documentation to assist future artists, and considerate<br>
> future-proofing for the several hundred unique full-colour icon files.<br>
> This sort of thing would probably be done over the span of 2-3 release<br>
> cycles in phases without assistance. I can commit to doing the<br>
> iconography required, documentation, and visual guides. Monochrome<br>
> icons would be untouched by this project.<br>
><br>
> If this were done, I'd imagine the rollout looking something like...<br>
><br>
> Phase 1: Mimetypes, Places (5.24)<br>
> Phase 2: Preferences, Categories, Devices (5.24/5.25)<br>
> Phase 3: Application Icons (5.25/5.26)<br>
> Phase 4: Possible second-pass for colour-science (explained below) (5.26/5.27)<br>
><br>
> Since Breeze has been well thought-out and users are accustomed to it<br>
> this would be a refresh - not a total redesign. An icon designed to<br>
> look like a CD jacket will still look like a CD jacket, but with the<br>
> following adjustments and "modernization":<br>
>  - Responsive colours added where appropriate / not obnoxious (e.g.<br>
> folders, various prefs icons, etc), an overall move to class-driven<br>
> colouring.<br>
>  - Removal of the 45-degree shadows, moving to softer top-down<br>
> lighting, more "logical" lighting.<br>
>  - Rounding and smoothing of the general design, as appropriate.<br>
>  - A secondary style tag named "extended-color-scheme" (explained below)<br>
>  - Retain the "mostly flat" design, but allowing depth where appropriate.<br>
>  - Overall a less "angular" and more "comfortable" design language.<br>
>  - Roughly the same amount of detail, give-or-take.<br>
><br>
> I have several sample icons illustrating...<br>
>  - Emblems in mimetypes and places following the text colour, with<br>
> appropriate soft glows/shadows.<br>
>  - Folders following the accent scheme.<br>
>  - Icons which can very slightly adjust some individual dark/light<br>
> levels to either provide contrast or subtlety for optimal visual<br>
> clarity in light/dark/moderate schemes.<br>
>  - The "extended-color-scheme" style tag (explanation below)<br>
>  - A new "ColorScheme-Toggle" class (currently does nothing, explanation below)<br>
><br>
> The accent colours are things that will get the community excited, but<br>
> in terms of usability and comfort any new icons should subtly re-shade<br>
> themselves to visually stand out just enough from the background to be<br>
> usable but not overwhelming. We have many icons that might feel "too<br>
> bright" or "too dark" under certain conditions. A major goal is to<br>
> ensure all icons are a pleasing luminosity without "sinking in" or<br>
> "popping out" of the system colour scheme.<br>
><br>
> "extended-color-scheme" is a style tag with a set of CSS classes<br>
> containing the 10 major colours in light/med/dark, and 3 shades.<br>
> Unlike the current-color-scheme style tag where every colour can<br>
> completely change, extended-color-scheme is more rigid (red is always<br>
> red, dark is always darkest). With this extended scheme we can much<br>
> more easily produce "vibrant" and "de-saturated" variants of the icon<br>
> scheme.  I'm midway finished producing a compile-time script for<br>
> optimization and colour modulation, so while Plasma itself might not<br>
> support this potential feature, it can be used to easily maintain both<br>
> "desaturated" and "high contrast/accessibility" icon variants ~ Phase<br>
> 2. In the future a pioneering developer may play with this "extended"<br>
> colour support as we currently do with system colours. If users wanted<br>
> a colour saturation slider or match the colours to their wallpaper<br>
> this gives us that future avenue.<br>
><br>
> Lastly, I'd also be adding the CSS class "ColorScheme-Toggle" to<br>
> select elements. Not everyone prefers the accent colour to dominate<br>
> their icons, so this class would provide a mechanism for icon authors<br>
> to allow disabling select colourizing in a flexible manner. The<br>
> primary example of this is folder icons where users may not want the<br>
> folders to follow their highlight colours. The mechanism to make this<br>
> work is to keep a copy of the current-color-scheme element during its<br>
> replacement, then doing a "dumb" text replacement of ".ColorScheme" to<br>
> ".ColorScheme-Toggle .ColorScheme" of its contents. In the Icons panel<br>
> we'd provide a checkbox labeled "Use accents from color scheme" to<br>
> manage this new behavior.<br>
><br>
> If this is done and support for extended-color-scheme and the toggle<br>
> rolls out, it will directly benefit community iconographers targeting<br>
> KDE Plasma, as they would no longer need to maintain several<br>
> variations of their sets in the future. While it theoretically means<br>
> more work on a per-icon bases, it dramatically decreases the number of<br>
> icons required and puts the focus of different icon packs to shape and<br>
> style. In my own work on this I'll be producing complimentary scripts<br>
> which will further assist the community in optimizing and deploying<br>
> these slightly more dynamic icons.<br>
><br>
> If a larger refresh is not needed I don't wish to push a larger design<br>
> effort onto the community, especially since it changes some of the<br>
> foundational style aspects of the icon theme, but this is work that<br>
> I'm able and willing to do. Between the strides of Plasma getting a<br>
> cleaner look/feel and competitors upping their aesthetic game, I think<br>
> this is a decent opportunity to keep pace in the graphical segment<br>
> while refreshing the iconography a bit. This requires effort in the<br>
> high-hundreds to low-thousands of icons, it would likely spawn several<br>
> phab tasks, so please let me know if you'd like me to begin this<br>
> initiative before I start making tasks which might pollute<br>
> Phabricator.<br>
><br>
> Thank you.<br>
>  - Ken<br>
</blockquote></div>