Find a way to specify whether to use monochrome or color icons in applications
Open, HighPublic

Description

We have a problem where we end up with monochrome and color versions of icons being used inconsistently. This problem exists in our own system settings, our own application settings, our own desktop shell and 3rd party applications.

We need a way to specify that a different icon style should be used in some contexts.

ndavis created this task.Jan 29 2019, 6:59 PM

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?

ndavis added a comment.Feb 1 2019, 5:05 AM

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.

ndavis renamed this task from Change all monochrome icons into `*-symbolic` icons to Create a way to specify whether an icon should be monochrome or color OR always use monochrome for 24px and less and always use color for 32px and more.Feb 3 2019, 8:16 PM
ndavis renamed this task from Create a way to specify whether an icon should be monochrome or color OR always use monochrome for 24px and less and always use color for 32px and more to Specify how to use and classify monochrome vs color icons.Feb 3 2019, 8:20 PM
rooty added a subscriber: rooty.EditedFeb 3 2019, 8:21 PM

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).

ndavis added a comment.EditedFeb 3 2019, 8:23 PM

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.

GB_2 added a subscriber: GB_2.Feb 3 2019, 8:26 PM

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.

ndavis added a comment.Feb 3 2019, 8:29 PM
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.

GB_2 added a comment.Feb 3 2019, 8:35 PM
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.

ndavis added a comment.Feb 3 2019, 8:40 PM
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:

GB_2 added a comment.Feb 3 2019, 8:44 PM
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.

ndavis added a comment.Feb 3 2019, 9:03 PM
In T10413#175165, @GB_2 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.

GB_2 added a comment.Feb 3 2019, 9:04 PM
In T10413#175165, @GB_2 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.

ndavis added a comment.EditedFeb 3 2019, 9:17 PM
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.
ndavis added a comment.EditedFeb 3 2019, 9:38 PM

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.

ndavis triaged this task as High priority.Feb 3 2019, 10:28 PM
GB_2 added a comment.Feb 3 2019, 11:35 PM

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:


GB_2 added a comment.Feb 3 2019, 11:42 PM

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.

ndavis added a comment.EditedFeb 4 2019, 12:50 AM
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)?

GB_2 added a comment.Feb 4 2019, 2:31 AM
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.

ndavis added a comment.EditedFeb 4 2019, 3:46 AM
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.

GB_2 added a comment.Feb 4 2019, 3:53 AM
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.

GB_2 added a comment.Feb 4 2019, 4:04 AM

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.

ndavis updated the task description. (Show Details)Feb 5 2019, 12:57 AM
GB_2 added a comment.Feb 5 2019, 5:28 PM

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.

ndavis added a comment.EditedFeb 5 2019, 5:59 PM
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.

ndavis added a comment.EditedFeb 6 2019, 10:18 PM

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

ngraham added a subscriber: mart.Feb 28 2019, 2:26 PM

From D19392:

In D19392#421905, @mart 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.

GB_2 added a comment.Feb 28 2019, 2:45 PM

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
GB_2 added a comment.Apr 29 2019, 11:40 AM

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.

ndavis updated the task description. (Show Details)May 3 2019, 1:52 PM

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
ndavis added a comment.EditedFri, Nov 22, 11:36 PM

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.

ndavis added a comment.EditedSun, Dec 8, 3:12 PM

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.

ndavis renamed this task from Specify how to use and classify monochrome vs color icons to Find a way to specify whether to use monochrome or color icons in applications.Sun, Dec 8, 3:17 PM
ndavis updated the task description. (Show Details)

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!

ndavis added a comment.Sun, Dec 8, 6:42 PM

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.