I'd always wondered whether we should have been using the -symbolic naming convention all along for small monochrome icons. Sounds like something we should do at the very beginning of a Frameworks cycle so we have a full month of testing before release.

Once the compatibility symlinks are in place and we start the porting, it won't just be apps; we'll need to hit all the Frameworks and Plasma too. Speaking of Plasma, might it be a good idea to move all of the icons out of the Plasma Theme first?

Hmm, even if we do get all of our own software using the symbolic versions, what are we going to do about 3rd party applications that don't use symbolic icons (list-add vs list-add-symbolic)? Is there a way to force symbolic icons to be used in 3rd party apps?

If those 3rd-party apps are targeting GNOME, wouldn't they already be using the -symbolic icon names since that's the naming convention there?

In T10413#175064, @ngraham wrote:

If those 3rd-party apps are targeting GNOME, wouldn't they already be using the -symbolic icon names since that's the naming convention there?

I don't know. I would expect some 3rd party apps to have support for standard icon names from the fd.o icon naming spec and target no DE in particular as well, which is how you might end up with an issue if it asks for list-add and we only have list-add-symbolic.

What about using a different suffix? Would that be too nonstandard? Something along the lines of "-monochrome" or "-mc", "-bnw" etc.

I'm not sure if size should be the deciding factor here, but it definitely is a factor (if the panel's really big it can handle color icons for example).

The suffix doesn't matter. I suggested -symbolic because it's already used by another DE and using it would improve compatibility. The important thing to look for is how to solve the greater issue of where, when and how to use monochrome and color icons.

I think we should only use monochrome icons for action icons, status icons and other low resolution icons that are mostly displayed at small sizes. Category icons, preferences icons or app icons should only be colorful, even if displayed at small sizes.

In T10413#175160, @GB_2 wrote:

I think we should only use monochrome icons for action icons, status icons and other low resolution icons that are mostly displayed at small sizes. Category icons, preferences icons or app icons should only be colorful, even if displayed at small sizes.

What do we do if a 3rd party uses an icon defined by the fd.o icon naming standard that we normally use in system settings as an action icon? For instance, preferences-system on a button in a 3rd party application to open up the application settings.

In T10413#175162, @ndavis wrote:

In T10413#175160, @GB_2 wrote:

I think we should only use monochrome icons for action icons, status icons and other low resolution icons that are mostly displayed at small sizes. Category icons, preferences icons or app icons should only be colorful, even if displayed at small sizes.

What do we do if a 3rd party uses an icon defined by the fd.o icon naming standard that we normally use in system settings as an action icon? For instance, preferences-system on a button in a 3rd party application to open up the application settings.

If you use a colorful only icon at a small size then fine, but if you don't want it then you'll have to use an action icon or other monochrome icons.

In T10413#175163, @GB_2 wrote:

If you use a colorful only icon at a small size then fine, but if you don't want it then you'll have to use an action icon or other monochrome icons.

I'm talking about issues like this:

In T10413#175164, @ndavis wrote:

In T10413#175163, @GB_2 wrote:

If you use a colorful only icon at a small size then fine, but if you don't want it then you'll have to use an action icon or other monochrome icons.

I'm talking about issues like this:

I'm afraid we won't be able to 100% ensure that everything looks right. The apps will need to be changed if they inappropriately use a colorful icon or a wrong size.

In T10413#175165, @GB_2 wrote:

In T10413#175164, @ndavis wrote:

In T10413#175163, @GB_2 wrote:

If you use a colorful only icon at a small size then fine, but if you don't want it then you'll have to use an action icon or other monochrome icons.

I'm talking about issues like this:

I'm afraid we won't be able to 100% ensure that everything looks right. The apps will need to be changed if they inappropriately use a colorful icon or a wrong size.

While is isn't our responsibility to include icons for every app in the universe, it is still our responsibility to make sure standard icons look right whenever they are used. BTW, this app is Inkscape 1.0.

In T10413#175166, @ndavis wrote:

In T10413#175165, @GB_2 wrote:

In T10413#175164, @ndavis wrote:

In T10413#175163, @GB_2 wrote:

If you use a colorful only icon at a small size then fine, but if you don't want it then you'll have to use an action icon or other monochrome icons.

I'm talking about issues like this:

I'm afraid we won't be able to 100% ensure that everything looks right. The apps will need to be changed if they inappropriately use a colorful icon or a wrong size.

While is isn't our responsibility to include icons for every app in the universe, it is still our responsibility to make sure standard icons look right whenever they are used. BTW, this app is Inkscape 1.0.

Monochrome category/app icons aren't standard though.

In T10413#175167, @GB_2 wrote:

Monochrome category/app icons aren't standard though.

We use standard icon names, regardless of whether they are monochrome or color though.
We will have to live with 24px or smaller always being monochrome and 32px or greater always being color,
or we allow monochrome and color to be used inconsistently at the same sizes (what we have now),
or we create a way to specify whether or not an icon is monochrome.

It's just not possible to make some types of standard icons only have color or only have monochome, because then the inconsistency gets shifted somewhere else. That is, without doing the 3rd option above. The problem with the 3rd option is

1. We would also need new color versions of all small versions of icons. That it would be starting over with all of the 16 and 22px icons.
2. Or we would need a way to force monochrome icons to be used in 3rd party applications when the size is less than 32px. That would be almost like the 1st option from the section above, except a lot more work and maybe not possible.

It seems like it might be simpler to choose monochrome or color based on size rather than category and usage. If we want to avoid using monochrome icons in a specific instance, we'll just have to avoid using icons at a monochrome size.

In T10413#175169, @ndavis wrote:

It seems like it might be simpler to choose monochrome or color based on size rather than category and usage. If we want to avoid using monochrome icons in a specific instance, we'll just have to avoid using icons at a monochrome size.

We're trying to avoid this:

What if we make -symbolic versions of category and application icons that are monochrome and the normal application and category icons are always corful. The action icons, status icons, etc are always monochrome.

In T10413#175171, @GB_2 wrote:

We're trying to avoid this:

I know, but I don't want to only move the problem over to 3rd party applications. We'll have to find another way to fix that.The simplest way to fix these might be to fix the issues in the software that uses the icons. That means not using 22px or 16px at all if you want color icons. For titlebars, we would need a way to apply titlebar text color from colorschemes to the icons via embedded style sheets. We already do that, but only for regular text color, not titlebar text color.

In T10413#175172, @GB_2 wrote:

What if we make -symbolic versions of category and application icons that are monochrome and the normal application and category icons are always corful. The action icons, status icons, etc are always monochrome.

But what do we do when a 3rd party application doesn't ask for a -symbolic version of a standard icon, but still requires a smaller version of the icon than the color version and needs a monochrome version to look consistent (back to the Inkscape screenshot)?

In T10413#175175, @ndavis wrote:

In T10413#175171, @GB_2 wrote:

We're trying to avoid this:

I know, but I don't want to only move the problem over to 3rd party applications. We'll have to find another way to fix that.The simplest way to fix these might be to fix the issues in the software that uses the icons. That means not using 22px or 16px at all if you want color icons. For titlebars, we would need a way to apply titlebar text color from colorschemes to the icons via embedded style sheets. We already do that, but only for regular text color, not titlebar text color.

In T10413#175172, @GB_2 wrote:

What if we make -symbolic versions of category and application icons that are monochrome and the normal application and category icons are always corful. The action icons, status icons, etc are always monochrome.

But what do we do when a 3rd party application doesn't ask for a -symbolic version of a standard icon, but still requires a smaller version of the icon than the color version and needs a monochrome version to look consistent (back to the Inkscape screenshot)?

That's how GNOME does it too.
BTW, most applications use colorful icons as their app icons anyways, so it would be inconsistent that some have monochrome icons and almost all not.

In T10413#175176, @GB_2 wrote:

BTW, most applications use colorful icons as their app icons anyways, so it would be inconsistent that some have monochrome icons and almost all not.

Then perhaps we need a way to make sure that a color icon is used in some places. Maybe find icon from scalable directory (defined in index.theme), then shrink to fit. I don't know how to make that happen or if it's feasible. It would eliminate our problem and allow us to avoid doing anything drastic. I should update the main task, because I realize that the whole symbolic thing was designed for a theme that normally has a color version of everything. We would also have to make a color version of everything. That's why I no longer think the -symbolic thing would work for Breeze.

In T10413#175177, @ndavis wrote:

In T10413#175176, @GB_2 wrote:

BTW, most applications use colorful icons as their app icons anyways, so it would be inconsistent that some have monochrome icons and almost all not.

Then perhaps we need a way to make sure that a color icon is used in some places. Maybe find icon from scalable directory (defined in index.theme), then shrink to fit. I don't know how to make that happen or if it's feasible. It would eliminate our problem and allow us to avoid doing anything drastic. I should update the main task, because I realize that the whole symbolic thing was designed for a theme that normally has a color version of everything. We would also have to make a color version of everything. That's why I no longer think the -symbolic thing would work for Breeze.

I don't think there's any way to tell an application to use the color version instead of the monochrome one at a small size.

I'm still for doing it like GNOME, I think it's the easiest and best solution:

• Provide -symbolic icons only for application/category icons that must have a monochrome version (will just be a few)
• Normal application/category icons are always colorful, even at small sizes
• Action/status icons are always monochrome
• If an app wants to use a monochrome icon it should either use an action/status icon or a -symbolic application/category icon

In T10413#175179, @GB_2 wrote:

I'm still for doing it like GNOME, I think it's the easiest and best solution:

• Provide -symbolic icons only for application/category icons that must have a monochrome version (will just be a few)
• Normal application/category icons are always colorful, even at small sizes
• Action/status icons are always monochrome
• If an app wants to use a monochrome icon it should either use an action/status icon or a -symbolic application/category icon

This makes a lot of sense to me.

If we would do it like described in the task description then application developers would need to figure it out too if they wanted to prevent it too.

In T10413#175379, @GB_2 wrote:

If we would do it like described in the task description then application developers would need to figure it out too if they wanted to prevent it too.

By "Prevent it" you mean prevent monochrome icons from being used? If so, I suppose they would, but only KDE application developers. In most cases, the way color and monochrome icons are used at different sizes is very straight forward and requires no special function to make it look consistent. Toolbars, buttons and application menu entries universally use monochrome at 16 or 22px. Sometimes settings have a sidebar with 32px icons for categories, but that shouldn't be hard to keep color as long as we make sure 32px and up is only color. The issue shows up mainly in the system settings, the title bar and Plasmashell when we try to use color at 16 and 22 px.

What if rather than all of this complicated stuff, we just used 24px for small color icons and deleted all preferences-* 24px monochrome icons? AFAIK, barely anything requires 24px icons. Just like what Nate did here: D18797

From D19392:

In D19392#421905, @mart wrote:

In D19392#421903, @ngraham wrote:

Actually we're discussing in VDG-land whether or not this is something we should do anyway, because right now we have no way of forcing the use of a monochrome icon for a >22px size when a larger colorful version exists. Using -symbolic to suffix the monochrome versions would allow us to do this. Adding some VDG folks for comment.

yeah, the decision of "this should always be monochrome" must be done at a semantic level by the app itself, and that's what the -symbolic name is for.
tough some icons wether they are on a way or the other purely depends from a style decision of the icon theme, so while i encourage using the symbolic name for places that should have a simple lineart symbol regardless of the icon theme, it doesn't solve the entrirty of the problem

So I guess the -symbolic suffix is the correct approach.

In T10413#177466, @ngraham wrote:

So I guess the -symbolic suffix is the correct approach.

So this?:

In T10413#175179, @GB_2 wrote:

I'm still for doing it like GNOME, I think it's the easiest and best solution:

• Provide -symbolic icons only for application/category icons that must have a monochrome version (will just be a few)
• Normal application/category icons are always colorful, even at small sizes
• Action/status icons are always monochrome
• If an app wants to use a monochrome icon it should either use an action/status icon or a -symbolic application/category icon

Figuring this out would be very useful for the new default Show Desktop widget.

In T10413#183297, @GB_2 wrote:

Figuring this out would be very useful for the new default Show Desktop widget.

For that specific issue, you can add monochrome icons to the Breeze desktop theme (plasma-framework) rather than breeze-icons.

OK, so we might have a way to progress with this, but this is getting a bit out of my depth right now:
https://lists.freedesktop.org/archives/xdg/2019-November/014204.html
https://lists.freedesktop.org/archives/xdg/2019-November/014206.html

The idea of using two themes seems sort of over-complicated and over-engineered to me.

What's wrong with our current approach of:

• Always use the monochrome style for ≤ 24px icons
• Always use the colorful style for ≥ 32px icons
• In the cases where we want to use a colorful icon for a list with ≤ 24px icons, we use icons that only have colorful versions. To my knowledge this is only something we do in System Settings

In T10413#209410, @ngraham wrote:

The idea of using two themes seems sort of over-complicated and over-engineered to me.

It could work depending on how it was done, but I don't know enough to say for sure. Ideally, the fact that there are 2 themes should be hidden from the users.

What's wrong with our current approach of:

• Always use the monochrome style for ≤ 24px icons
• Always use the colorful style for ≥ 32px icons

It's not really a current approach yet since we haven't actually made any progress towards making that the approach we use.
Here are my concerns about committing to the style change:

• We're compromising our design because of a limitation in the system we're working with. The system was really only designed to handle icon themes with one style.
  • Based on the design of Breeze, I believe the original intention for Breeze was that monochrome icons would be used for buttons and menus. It would be nice if buttons/menus always used monochrome icons instead of switching style depending on the size.
• I don't see using only color icons at 32px (including buttons/menus) as visually superior and my confidence in whether or not I will be able to make 202 color icons that are good replacements is not high. If I take all the time I need, I suppose I could do it, but it would take a very, very long time.
• I'm trying to branch out and learn different skills. If I spend all my time contributing to KDE on redesigning icons because of a flaw in the system, I won't grow the way I want to grow. I don't want to burn out on KDE either and doing the same thing for ages will do that. Icon work in particular can be frustrating and tedious, partly because I don't know any people with many years of experience in icon design to talk to. Most of the design process is just me working entirely in my own head, arguing with myself.
• Do we really want to keep using the desktop theme for icons forever? It's a hassle. I remember that we wanted to switch to Kirigami/QQC2 to reduce the maintenance burden, which means desktop themes would only be used for icons. Most of the icons would be duplicates of icons in breeze-icons and a few of the larger monochrome icons we will remove from breeze-icons.
• People will complain. Yeah, some people always complain, but I think it will be pretty unpopular.
  • Some 3rd party apps use 32px icons for toolbar buttons.
  • Some people set their toolbar icon size to 32px.

In the cases where we want to use a colorful icon for a list with ≤ 24px icons, we use icons that only have colorful versions. To my knowledge this is only something we do in System Settings

This is not foolproof. Anywhere in SySe that an icon name from the XDG naming spec is used, we will have to use an icon with a custom name, breaking compatibility with 3rd party themes. This is because 3rd party developers (even some KDE apps are like this) often design their applications with the assumption that icon themes only have 1 style and use icons like preferences-system for settings.
This leads to situations like this: https://gitlab.com/inkscape/inkscape/issues/431
We can fix the button size problem by making smaller versions of preferences-system, but we cannot make a monochrome version of it or else we will see the monochrome version used where we don't want it. To be fair, the giant button issue is a GTK issue, but the icon style consistency issue remains.

Update with a conversation I had on #kde-devel: https://webchat.kde.org/#/room/#kde-devel:kde.org/$157537933341042bwtvA:kde.org

Another idea from that conversation was to append -symbolic to icon names requested by applications for buttons/menus and then make all monochrome icons use the symbolic suffix.

In T10413#213130, @ndavis wrote:

Update with a conversation I had on #kde-devel: https://webchat.kde.org/#/room/#kde-devel:kde.org/$157537933341042bwtvA:kde.org

Another idea from that conversation was to append -symbolic to icon names requested by applications for buttons/menus and then make all monochrome icons use the symbolic suffix.

This seems like it could succeed, but would require a lot of porting work in applications. Then again that work could be phased in over time because the icon name changes would be forwards-compatible. And they could make be scripted too. Sounds like this could be a way to break the logjam!

In T10413#213139, @ngraham wrote:

In T10413#213130, @ndavis wrote:

Update with a conversation I had on #kde-devel: https://webchat.kde.org/#/room/#kde-devel:kde.org/$157537933341042bwtvA:kde.org

Another idea from that conversation was to append -symbolic to icon names requested by applications for buttons/menus and then make all monochrome icons use the symbolic suffix.

This seems like it could succeed, but would require a lot of porting work in applications. Then again that work could be phased in over time because the icon name changes would be forwards-compatible. And they could make be scripted too. Sounds like this could be a way to break the logjam!

Ideally, it wouldn't require any porting. It might be doable in the QStyle.

JFYI I've also filed a Bugzilla ticket for this: https://bugs.kde.org/show_bug.cgi?id=417969, mostly to be used as a collector for duplicates so we can get an idea of how widespread the issue is in practice for our users.

Another idea from that conversation was to append -symbolic to icon names requested by applications for buttons/menus and then make all monochrome icons use the symbolic suffix.

IMHO this is by far the best solution, because the icon specification explicitly states that if foo-something doesn't exist it'll search for "foo".

We can then force everything in the panel to be symbolic by having the system tray (or whatever) just append "-symbolic" and everything would just work all in one single easy codepath.
Even if you end up appending "-symbolic" twice nothing will break due to the existing fallbacks.

It gives us GTK compatibility too.

Then in KF6 we can hopefully kill the concept of Plasma having it's own idea of icons.

Great, sounds like a path forward.

IIRC marco didn't like it for some reason

:/ I was about to say how glad I was to hear that we have a clear path forward. @mart What didn't you like about it and what would you suggest doing instead?

Also, do we need to implement this separately for QML apps, Qt Widgets apps and Plasmashell?

Marco said he wasn't actually against it.

What if we also had another suffix for requesting color icons when a widget style defaults to using symbolic icons? I think that unless we have a way to specifically ask for color, we might run into different problems.

@ndavis can you elaborate on the scenario, I don't understand

In T10413#234816, @davidedmundson wrote:

@ndavis can you elaborate on the scenario, I don't understand

@davidedmundson In Dolphin and File pickup the folders icons become monochrome when size is smaller than 32px. With a weird behaviour when video size is switching from 125 and 150% with 22px icon. It would be great if that particular type of icon remains colorful.
Thanks for taking into consideration.
Gianluca

See also https://invent.kde.org/frameworks/breeze-icons/-/issues/13