"Blue Ocean" Full-Colour icons refresh

[kainz.a]

That's great Ken, I love your work.

However I already work on a MR to use the highlight color for the places
icon see
https://invent.kde.org/frameworks/breeze-icons/-/merge_requests/141

Let me know if I should finalize the MR or you will jump in.

5 Years after my last icon work for breeze I come back
and 2 weeks later the awesome Ken. That's fantastic.

cheers
Andreas_K

Am Mo., 18. Okt. 2021 um 21:30 Uhr schrieb Noah Davis <noahadvs at gmail.com>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/visual-design/attachments/20211019/d227efd9/attachment-0001.htm>