While the technical workflow improvements sound nice, I can't say I'm that big a fan of the proposed icon style. Something about the usage of black and white in this manner shown here just doesn't sit right with me, though I can specifically point out that it's low contrast with a lot of background areas and the bordering looks out of place compared to other elements which are generally unbordered.

In terms of maintainability, this style looks like it would raise the barrier of entry to icon making more than having to work around our limited SVG renderer does already. This style is very complex, with light and shadow details that will be hard to replicate for new and/or time-squeezed icon makers. Even our current and modest hard bottom shadow (w/ maybe hard 45deg shadow) is often missed out on or hard to do for icon makers.

Also, how does this look with app icons, which make up the bulk of the colourful icons that users will be seeing on Plasma and on KDE software outside of Plasma?

Handful I would like to see compare/contrasted against versions in the new style if you wouldn't mind:

• cuttlefish
• kolourpaint
• okular

The black/white styling does look more awkward in the samples than in actual use. I think it's in part because these icons appear inconsistent when viewed beside each-other in their different modes, and the subtle shading/lighting plays also some tricks on your eyes as well. Kind of the reverse of that optical illusion with the cylinder on the checkerboard, in this case you think they ought to be the same colour, but they aren't. In practice (at least on my limited run of test icons on my own system) that effect isn't present.

I'm not quite sure what you mean by the bordering though? Do you mean in respect to the Breeze widget theme, or internally in the icons?

Beyond that contrast can be toyed with as well, when I get the apps sample together I'll include some variants with different contrasts.

Maintainability - General
Maintainability has been a significant driving factor in some of the design decisions. I tried to aim for something where even if an icon doesn't hit everything it'll look close enough fit in. But yeah, there's higher barriers to entry in some places for sure, and while the tooling will take out some of the most painful areas that same tooling could be used on easier-to-produce icons.

At the same time though the competition including Gnome, Windows, and MacOS are raising expectations. I think even if we distill the icons to their most simple form there will be cases where authors break the spec; in Breeze official I'm even spotting icons taken right from previous generations of sets, including Oxygen and even Crystal.

Maintainability - Mimetypes, Places

For mimetypes and places the tooling would completely mitigate that pain-point; to add a mimetype you more less just add the ingredients to the recipe book. New emblems will need to be created from time to time, but it's actually very little work and I'll write a guide to create them easily. For mimetypes that may have hand-touches, I think they'll be relatively few and far between.

Maintainability - App Icons

On a high level applications will always be tough regardless of spec because of their uniqueness and constant influx of new applications. There are some applications we can't create icons for due to legalities, and due to the different nature of application icons it's impossible to impose a standard and not have issues in some cases. I didn't get too deep into exceptions in the spec mostly because the proposal was already running long, but here's my thoughts on app icons...

• By removing the 45-degree shadow the more skeuomorphic application icons move closer in-line with symbolic app icons, and there are fewer places where "forced" shadows are added where they don't make sense. More/less if they aren't there they can't be forgotten. :P
• Application icons would be the one area where I'd recommend authors forego the more advanced aspects of the refresh around palettes for several reasons:
  • Palette swapping might break branding aspects. If Bluefish turned green it might be a tad silly.
  • Some apps representing "things" (like maps, globes, flames) would break. "When did the earth turn pink and orange?"
  • Applications providing their own icons would appear out-of-place.
  • The work would never actually get done. It's enough effort to create one solid icon, nonetheless >300, nonethelessnonehteless >300 adaptive icons.
  • We can still treat some select icons with things like accent colours to get the polished effect. The file manager, calculator, calendar, and icons mimicking GUIs could go above-and-beyond.
  • The soft edge shadows are more/less an additional iteration on our current method for producing edge shadows, and are only more apparent on HiDPI displays. If an author can't do the soft shadow it's not a total deal-breaker, and because the methods build on each-other other artists have an avenue for softening the shadows in a second pass, if needed.
• Building on the above points and exceptions, a huge number of applications icons would only need minor tinkering to be fully updated and polished.
• Lots of big cross-platform applications tend to follow Windows icon trends, so over time as they "Windows-11ize" their icons the refresh is designed to help them blend in.
• Roundness/softness is applied as appropriate. Square and sharp isn't preferred, but isn't a deal-breaker either.

In general, as long as we can get authors producing app icons roughly similar to the current Breeze icons sans 45-degree shadows, they shouldn't be overtly out of place.

Maintainability - Devices, Other Unique Things

These sorts of icons would certainly play to that higher bar. Ideally nobody will invent any more computer form factors ever again, but I don't think we'll be so lucky. My hope on this front is that once we refresh existing icons and (especially for devices) create the necessary anticipatory device icons (e.g. foldables, wall-types, watches, contemporary innards) that future icons shouldn't be overly concerning. Ideally we'll have enough examples created, along with refined guides and tutorials that if I'm hit by another bus there won't be any issues. Though with applets and a bunch of other icons in this group we're already fully using pretty robust techniques.

How Would App Icons Look

I'll get a few samples together fer ya. :)

I'll do up those 3 you mentioned, and some shading variants on the folders as well as one of the mimes. I'll also present them with light and dark icons are separated so they'll be seen in a scenario closer to "real world" usage.

I like the idea of adding accent colors to some icons :) As for the design, I very much like the new forms but I'm a bit hesitant about the black/white shadows. It's a cool idea but I better wait for the few more icons to see how this could looks with other icons.

It's high time we updated the colorful icons, so +1 in general.

Overall I like what I see and your proposed new design principles. I like the idea of dark/light adapted icons. And following our modern top-down lighting model is a good idea too. However there a few things I have some visual concerns about:

1. The corner radius seems a bit excessive to me. I'd tone that down a bit. Not all the way, just a bit. A bit. :)
2. Adding a contrasting glow/shadow around the icon's inner emblem seems somewhat unnecessary to me. In general I don't hate it, but I don't love it either. In particular for the emblems with a lot of line-art, I think it leads to an excessively glowy and distracting effect. I think making the effect more of an outline than a glow/shadow might look better, especially if the outline color were made *less* contrasting. Essentially, instead of ensuring contrast with an outline effect, I think it would be best to do that with the emblem's fill color (as current Breeze generally does), and use an outline purely for stylistic visual embellishment. The general tone we were going for with the Blue Ocean redesign was "more flat than Oxygen, but more ornamental than Breeze."
3. Not a huge fan of the "Oxygen crease." :) To me it always looked way too wide to actually be a real crease, which would be thin and liney.

Technically, if we could have a single CSS file and then somehow import that into the icons or embed it at built-time or something, that would be amazing. One of the biggest pain points of the current workflow is having to manually fix up the embedded CSS after you run an SVG optimizer. For that matter, optimizing at build-time would be nice too, but that's more of a technical thing unrelated to this proposal. :) Overall I like your maintainability ideas, as currently we are very bad here, so there's practically nowhere to go but up.

I don't like the oxygen like folder layout. cause I don't know what the horizontal element at the bottom of the folders is for.

What I like is that you use more rounded corners (similar to the rounded corners that breeze theme use)

What is realy cool is the use of the outlines so that you have more contrast AND it has some depth.

About monochrome icons we use now 1px line icons if you have a look at gnome and I think also other icon themes, and also at the proposal the symbols on the folders aren't 1px thin lines. As it's way easier to visible, I would prefer to go that way, but than we have to update ALL action icons (which is ok for me)

About shadows: Our icon's are VERY complex with the colorScheme stuff, ... so if we can live without shadows, go for it. We have to think also for contributors how will submit an icon and not the 1.000 breeze icon.

I think I got most of everyone's feedback in, and I managed to increase the internal "standards" of the icons which should also help when the documentation can give more solid direction.

Here's the icons at 100% scale (standard DPI)

And the icons at 300% DPI (for closer inspection)

Here's a summary of changes:

• Rounding has been reduced to 2px on corners in places where it was previously 4px.
• The glow around many elements has been removed.
• Emblems & graphics on folders and mimetypes are now 60% transparent, as opposed to 80% which looked pure black/white.
• Emblems & graphics now use a 40% opacity line (pencil width) which is simpler to implement.
• The crease in general has been made thinner, no longer uses gradients.
• Other overlays are standardized to 30% transparency. The crease is now in this style.
• Highlights and shadows have had opacity standardized to a lower value.
• Lighting has been adjusted, standardized, and simplified to a degree internally (while maintaining the adjustment effect).
• The overall light source uses a radial gradient in lieu of a linear gradient, giving slightly more defined left-and-right edges on light schemes.
• Icons have been adjusted to make themselves blend in more than pop.
• Added the requested application icons in the new style.
• Overall, authoring should be a bit easier.

On the application icons:

• Rules in terms of how you light an icon are looser. As long as the light source is coming from the top, we're happy.
• Okular uses the more rounded style. The other two were already appropriate.
• While the adaptive soft shadow and lighting is present on these samples, it is not required.
• The new lighting model is easier to implement since it's either pure black or pure white.
• In general the "fancy" features are optional perks.

@ngraham

On CSS and build-time, I have tools which will be shored up once the general style has been more/less cemented. There's an assembler for mimetypes, which will help with consistent mass production via "recipes". After that is a pair of tools for authoring and build-time. The authoring tool includes a validator which spots evil hardcoded values, and will back-up then automagically swap the hardcoded colour for the appropriate CSS class and currentColor. The validator would have two modes, one for colour icons and one for symbolic icons, and will use the appropriate pallette (system colours for symbolic, extended colours for full colour, also respecting pure black and pure white on colour icons). The validator will also populate every icon it touches with the full CSS sheets, it will set the sodipodi grid to use major gridlines every 4px, and pre-populate some gradient definitions. Running the validator on an empty SVG will fully prep it for authoring. The build time tool more/less is the optimiser which will remove unused CSS classes, sodipodi, and all that when exporting icons to their install location. It won't be the most robust optimizer, but it should be good enough that we can remove some of the annoying steps authors need to take while making icons, and over time I'm sure enhancements will make it our new best friend. Both of those together should also help keep icons in an easier-to-work-on state, without sacrificing the "binary" filesize.

I don't like the folder icon with this bottom horizontal element. Sorry but I don't know what it should mean.

I like the audio icon at least in dark mode it's very sexy on light mode it can be improved.

For the picture mime, I don't know why you have there an donkey ear.

For the folder it's meant to be a crease, and I must say it's been pretty divided been love-it-or-hate-it. I added it as a throwback to Oxygen while also using it to differentiate our basic folder design. The crease has become a little more abstract over the revisions, but that's not necessarily a bad thing. I'm personally becoming torn, because on one hand this is meant to be a refresh (I want to avoid excessive changes compared to current Breeze unless it's really warranted, or an existing icon breaks HIG) but on the other I think most folders look kinda bland. In terms of detail though we're going "a little more ornate than current" but otherwise the basic icons should feel mostly the same, and I'm trying very strongly to keep the basic silhouettes intact. I have a feeling it'll probably come down to a vote, but unless the crease wins by a good margin it'll go the way of the dodo because this is a refresh and it is a difference.

For the audio icon I have made a few adjustments, and it also more nicely fits into the aforementioned standards!

On the picture mime, it's eared to keep it in-line with the existing mimetype silhouette. Not sure who did the original, but I too would slap someone upside the back of the head if they folded a photo like that. Probably because most other mimes are folded like that... If other people feel strongly about it though I'll unfold the corner, but unless there's consensus it's what our users are familiar with even if they are corner-folding monsters. :P

About the crease how would the folder icon look like with thumb previews? Cause at Music folder it didn't look like a benefit to have the crease.

What I like is the use of colors for specific stuff. Like windows and als uri (at maui apps) did with image and audio folders.

• The image folder is blue and I think also that the image mimetypes will be blueish.
• The audio folder is orange / pink and the audio mimetype icons will have also similar colors
• or at least the main mimetypes use the "folder" color.

maybe you can make the audio folder look like a live rock stage and the video folder use darker colors and look like a cinema?

The benefit would be that dolphin didn't look that blueish.

can you share the svg file. I would be interested to play a bit, if it's ok for you.

I also just don't like the crease at all, sorry. :) It's just, not, well, crease-like. A real crease is a very subtle thing on a folder. It's practically invisible. I also wonder whether it still serves any value. Today a lot of people have probably never even seen a real manila folder.

I think you're right that we are shooting for a little more ornamentation, but to me the crease doesn't add that in a satisfactory way.

Anyway this is pretty bikesheddy, and I really like the rest of the changes

On the crease, I'm going to remove it. It's a love-it-or-hate it addition, and the fact is people who *would* love won't know they're missing it, and people who hate it *would* see it. It's not a hill I'm goanna die on, and I don't like bikeshedding over a line.

On colouring the folders, with mimetypes they'll be a variety of colours as they are now, so there's not really one "correct" colour we could make an audio/image/etc folder. An orange audio folder potentially filled with purple MP3s and a green pictures folder potentially filled with yellow images would seem wrong, and if we wanted everything to match it would require an overhaul of the mimes. Even if we recoloured the "main" mimes, what constitutes a "main" mime varies differently depending on what someone does; the "main" image mime for a photographer is totally different than the main mime for designers or someones family photos. Going back to this being a refresh I don't want to make significant changes, if adding a line to the folders had so much debate... Rearranging all the colours would be my death and this would never finish.

One thing that would be super-neat to do on the code side: In the icon picker it would be an interesting option to set per-icon accent colours, like putting the accent picker in the colour scheme editor into the icon picker. The KIconLoader would need to track that metadata somehow, but it would be a very flexible way of colouring... Anything that supports it! It would also depreciate the need for shipping several of the coloured icons in the future. That's a different topic though, but we do have avenues.

So with this revision there's a few more tweaks, adjustments, etc. The most obvious is the new Okular icon, I've learned that the Okular maintainers preferred the Oxygen style and that an icon more similar to this was produced. In general my plan is to keep app icons the same (but updated) unless the app maintainer/author requests a bigger change, which I think is a great time to accommodate those requests. App icons aren't really being targeted yet so I'll stress these are just sample app icons, if there's feedback on them I'd really like to stow that sort of thing for later and focus on mimes and places for now. Like, *maybe* some of the key apps might be updated, but think of this like the Breeze Ocean transition where it's a gradual process.

In the preview I've just been manually setting the light/dark stuff, it's super-messy, not validated, and not optimized. I think stylistically it seems settled, so I'm going to move on and begin the work necessary to start mass production of the icons, so if you don't mind waiting a day or two you can get some of the early "real" icons which are actually adaptive to play with very soon. There's several hundreds of icons that need to be built, so unless anyone has an "I object!" to shout, I'd like to start the heavy lifting.

A screenshot from index at the Maui framework. Done by Uri and his team.

About colored folders I'm thinking on something like this. I know we can theme all the icons but have all folder's blue / pink / gray / ... is "cool" but from recognizion point of view different colors for different folders would be a recognizion benefit.

If you think it's complete new for breeze, check user-desktop icon it's very visible in the home dictionary.

when you use the plasma accent color you have at the end folders in blue, green, ...

As in general you have in a directory a number of folder icons, they are all the same so define a folder for music, video, github, development, gaming, ... will make the specific folders more unique and so easier to recognize.

Oh yes, I understand it. The issue is that it's a big divergence from Breeze current, and this is just meant to be a refresh. That being said I *have* investigated the source for the SVG modification in the icon code, and I think there's an avenue to provide configurable icons.

Imagine this: go to the icons kcm, and much like the window decorations there's a configuration button. In it we have 3 options:

• Hide folder crease
• Standard folders use your accent colour
• Places folders use different colours

On the icon set side it's adding classes to appropriate tags, along with ini keys with the class=>label pairings. On the code side its pulling the ini options, and removing the classed tags if disabled. We have a shocking amount of the necessary plumbing.

So for the refresh, I'm absolutely keeping it as close to Breeze current as possible. Once either I or someone else implements the code to support configurable icons, we can absolutely add these divergences (even add the new defaults) and users who don't like the changes can un-check those boxes. I'm hoping a more experienced developer wants to work with me on this though, as just doing the icons alone is a sizable workload.

about the options idea

• Hide folder crease -> can be done with an separate breeze icon theme where you have the folders with creases. Everything else wasn't needed cause the fallback is breeze
• Standard folders use your accent colour -> no real issue cause the standard accent colour is the colour the folders use by default
• places folders use different colours -> we already have this eg. for desktop, encrypt, as I'd like to implement more specific places folders see https://bugs.kde.org/show_bug.cgi?id=443288
• places folders use different colours -> mimetype icons use also different colors to separate them easier

places folders with the colors from the mimetypes.

I prefer the more fancy folders from here. Also I like the solid icons from @kvermette with some outline for better contrast.

The options thing isn't just for Breeze; other icon sets can provide completely different options for their own stuff. The big selling point, to me, is the idea that one icon theme can provide slight variations like the crease or multicolored place folders without resorting to maintaining entirely separate themes. This also clears a large workload from iconographers who can consolidate their work. If this wasn't a direction we could take, I'd probably be forcing the crease down your throats! :P

On the specific points though:

• The folder crease, as a toggle-able option, would make my life way easier if I didn't have to maintain an entire second icon set for just that.
• Out-of-the-gate we'll use accented folder colours, yes. But an option to fall back to a more neutral manilla colour is my plan, as over-using the accent colour might become overwhelming. I even debated standardizing on blue (despite built-in capability), but technically on a vanilla system they would be blue anyways.
• I know the encrypted folders are a different colour, but they're also very functionally different than a normal folder.
• We could also absolutely have mimetype/folder colouration be the option. "[x] Synchronize File type and Place colours"

The options I came up with were off the top of my head, but the potential is there once we figure out the details.

So I guess the options would actually be more like...

• Show a crease in folders
• Use manilla instead of the accent colour for folders
• Synchronize file type and place folder colours

In general my plan is to keep app icons the same (but updated) unless the app maintainer/author requests a bigger change, which I think is a great time to accommodate those requests

Relevant: T10243

In T14968#265464, @kvermette wrote:

I feel like the inner emblem needs better contrast for the light theme icons. It's quite good for the dark them icons, but for the light versions, the emblems just look too dark to me.

For posterity this is the first iteration of the builder tool, along with some of the initial output results, the initial places "cookbook", and the folder assets which have been prepped.

By running compile.py in the command line it will instruct you on what's needed for it to run if you're missing any dependencies for building. It will then scan either the specified cookbook or all cookbooks in the folder. For now it outputs the build status of every icon in the command-line, it might save a log later if that's desired, but for now I've found the command-line output sufficient. The pictures folder does not have the embedded image, and you can see it will inform you of what's missing in the output, and the ideal sizes for missing graphics.

There are limitations to the tool, which will be documented, and there's also some minor upgrades which may come later. For example, the svg tag itself doesn't take on attributes from embedded components, and I'm debating whether or not the rect element which denotes the location of embedded files should hold metadata which isn't standard, or if it's better to keep that data in the cookbooks; I'll be expanding out the icons over the coming days and keeping an eye on whether or not the exact size behavior is fine or if more flexibility is needed.

There's a couple todos still. First is the script isn't yet producing aliases (this is in part so I can track generated content more easily). This also doesn't yet do any form of optimization outside of the assembly. In terms of assembly optimization the tool avoids inserting duplicated tags. There is some moderate logic around the "defs" tags, as it will merge in definitions separately from the contents being merged together to better optimize the output and make for more readable source files. You'd be hard pressed to tell me some of these icons are 2-3 files merged together by viewing the sources alone. I did have a brain fart in my logic and had to disable one optimization in def merging, but it's lower priority.

In the future when we aim for fully optimized output I'm actually *more* confident that our build tool can aggressively optimize our entire range of icons, which will allow us to forego having authors manually optimize their icons while encouraging authors to keep their editing masters in their most robust formatting. Once this is further along it's very likely we'll even be able to recommend authors embed icon guide layers and rulers in their working documents.

On an aside, actual maintenance is already proving to be easier, and it's only going to get better. This tool is generating 78 icons at the moment, and when I needed to correct some shortcomings in the templates only 18 files needed to be worked on - the number could have easily been 6 if I wasn't a keener. Once the cookbook is loaded with all the various places there's going to be 264 icons generated for our current crop of folders, and that number will inflate to 468 once we include newly added folders - but maintenance will remain limited to the 18 templates for wide-ranging changes. This same efficiency impact should be felt across our mimetypes.