"Blue Ocean" Full-Colour icons refresh

[Noah Davis]

Hi Ken, this sounds like a really cool idea and I'd be interested in
seeing what you have in mind.

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