Adapt Papirus to KDE Plasma 6

[lhy7889678]

A message from maintainers:

• This issue collects all known issues and bugs regarding the transition from Plasma 5 to Plasma 6!

• Before reporting a new problem or bug, please check if the problem is still present when using the latest Papirus git master (use install script in our root directory, see project README)

• For useful background regarding new symbolic icons in plasma 6, see Plasma 6 applets use system icons so missing many icons for applet #3595

• Please understand that Papirus icon theme had already included symbolic icons prior to the Plasma 6 release and those icons now show up in plasma as unthemeable (either dark grey or white, they don't follow the text colour of your colour scheme). You need to use Papirus-Dark for these icons to appear white.

• Please report such icons, but acknowledge that this is something that can only be fixed with some restructuring within Papirus, possibly even splitting the theme in two (KDE and GTK editions).

FAQ

Q: I use Plasma and have Breeze-Dark theme applied. Symbolic Papirus icons are white, but sometimes an icon stands out because it is dark grey. How to make solve this issue?

A: Apply Papirus-Dark instead of just Papirus. While the majority of symbolic icons will adapt to your text colour, these GNOME symbolic icons will not, because they were not intended to do that by Advaita developers. Manually choosing the Papirus flavour will make them blend in with other icons.

Q: I applied the appropriate Papirus flavour but the problematic icons appear blurry when compared to others. How to solve this?

A: These icons have a fixed size of 16x16 pixels, because that's how the modern GTK apps use icons. Most of our icons have different sizes (16px, 22px, 24px, 32px, etc.) so that they render crisply in all situations. However, these GNOME symbolic icons only render correctly at the context of symbolic icons at 2x scale (16, 32, 64, 128, 256px). If they are on a panel where the icon size is 22px (Plasma panel by default), they will appear blurry. Adjust your icon size to be either 16px or 32px or use margin separator widgets on Plasma panels to separate different icon sizes.

Q: How to resolve this whole mess?

A: Advocate for a unified symbolic icon implementation between GNOME and KDE so that icon themes like Papirus are able to make one icon for every desktop environment and have it not look awful. If one spec-compliant icon theme is in practice incompatible with some desktop environment, what is the purpose of the specification?

Original message:

KDE Plasma 6 seems to have changed the names of some icons used in the system tray / system settings / etc. As a result, these icons will fall back to the default Breeze icon theme, even though Papirus has adequate icons (with different names) for them.

Here is a list of icons that I have noticed so far:

• brightness-high-symbolic, redshift-status-off-symbolic, redshift-status-on-symbolic, redshift-status-day-symbolic: Used in the brightness controller
• klipper-symbolic: Used in the clipboard manager
• notifications-disabled-symbolic, notification-active-symbolic, notification-inactive-symbolic: Used in the notification manager
• kdeconnect-tray-symbolic: Used by KDE Connect

(everything above could also have their counterparts without "-symbolic")

• network-flightmode-on: Used by the network manager
• input-touchscreen: Used by system settings

Note that this is not an exhaustive list. Maybe we can refer to the new Breeze icon theme repository to find what's not included in Papirus.

[Bingo90]

The removable devices tray icon also shows a colored version, not a monochrome version - not sure this is intended

[stengun]

Relevant post from Nate:
https://pointieststick.com/2023/08/12/how-all-this-icon-stuff-is-going-to-work-in-plasma-6/

[d-avery]

I was about to make this same issue! Papirus is my favorite icon pack. Looking forward to using it with Plasma 6!

[monstorix]

Panel related adaptions was once mentioned by #3595.

[archisman-panigrahi]

Plasma 5

Plasma 6 (please ignore the annotation around the battery. Also the power icon changing to Plasma icon is a bug with that applet, it is not a Plasma issue.)

[dmaliog]

I support we are waiting for Plasma 6! Papirus is the best set!

[morganist]

do we make the symbolic klipper icon to be a generic metal clip icon ( ) used for clipman in xfce, for example? or perhaps a better solution would be to draw a new icon that would be more similar to the one breeze icon theme uses? ( )
also, we have a few klipper icons in various old plasma themes. those could be used too.

[morganist]

Okay guys, I don't think it is possible to have a solution right now. KDE colour scheme icons currently only have sizes up to 24px in Papirus, but the ones that were previously used inside the Plasma themes need to have 32px and 22px sizes. There's no place for symbolic 32px icons at the moment. And even after figuring out where to put them, the necessary scripts for preparing and converting the icons need to be modified. I managed to assemble a quick-and-dirty solution, but I think it is better not to merge it. We need restructuring. I guess I can finally understand what @SmartFinn meant by his harsh reaction to this change in Plasma 6.

[morganist]

I could even start adding some necessary 32px symbolic icons myself, perhaps in the apps folder or in a new folder somewhere, but I'm not experienced in the project structure and script writing, so I'll be waiting for Serhii to say his word.

[monstorix]

I could even start adding some necessary 32px symbolic icons myself, perhaps in the apps folder or in a new folder somewhere

It looks like KDE has done something similar to Breeze Icons 6. In one of Nate Graham's blog posts he said that Plasma 6 will adapt to the way GNOME uses the -symbolic suffix, which may mean that icon makers can put the symbolic icons in all sizes, alongside the coloured ones.

[morganist]

which may mean that icon makers can put the symbolic icons in all sizes, alongside the coloured ones.

@monstorix we could, but as I've said we need some non-trivial restructuring. The situation is dire because symbolic icons which are used in GNOME don't adapt their colour, but the icons with the KDE colourscheme support do. And now they are mixed up. I haven't given it much thought, but it seems like another challenge.

[SmartFinn]

Sorry, I don't have enough time to install KDE on my laptop to see the changes. I suppose that @monstorix @morganist is right, this is required some major changes to Papirus icon theme. KDE may need 22px, and 24px symbolic icons, that we don't support now.

I wrote a script that converts 16px icons into 22px, and 24px, sometime ago. So it shouldn't be a problem. However, we should find the right icon theme structure at first. Another way is creating a fork for Plasma 6.

[monstorix]

Another thing that may affect the works:
KDE VDG team is currently in the process of fully migrating (redrawing) the 22px Breeze icons to 24px, for better cross-compatibility with GTK size. Which may imply that Plasma will finally settle with 24px for standard monochrome/symbolic icons instead of 22px in current 6.0 version.

[SmartFinn]

Honestly, I can't remember any place in GTK where 24px icons are used. GNOME uses 16px in menus, buttons, panel, sidebars, and toolbars. 22px is using for appindicators and tray.

[monstorix]

Well, the GTK compatibility saying is also from Nate. It might not pointed to any specific DEs.

[Bingo90]

Couldn't we just use the icons from the Materia theme? They seem to fit quite well!

[morganist]

Couldn't we just use the icons from the Materia theme? They seem to fit quite well!

The problem is, every icon in materia plasma 5 theme (in all of them, really) has both 32px and 22px shapes inside the file: small icons are used for the panel and the bigger ones appear when you open the systray widget. Papirus has no place for these 32px symbolic icons yet, that's why it's not so simple.

[Bingo90]

Couldn't we just use the icons from the Materia theme? They seem to fit quite well!
The problem is, every icon in materia plasma 5 theme (in all of them, really) has both 32px and 22px shapes inside the file: small icons are used for the panel and the bigger ones appear when you open the systray widget. Papirus has no place for these 32px symbolic icons yet, that's why it's not so simple.

We'd have to do a lot of it manually, I guess, but for icons that we don't have in Papirus, we could just extract the 22px versions and put them in a separate SVG

[morganist]

We'd have to do a lot of it manually, I guess, but for icons that we don't have in Papirus, we could just extract the 22px versions and put them in a separate SVG

That's what i did locally before realising that we need restructuring. I've used plasma theme with materia icons myself.

[morganist]

Honestly, I can't remember any place in GTK where 24px icons are used. GNOME uses 16px in menus, buttons, panel, sidebars, and toolbars. 22px is using for appindicators and tray.

@SmartFinn if understand correctly, the KDE developers are talking about compatibility in a broader context — 22px icons aren't present in GTK at all, are they? That's why they want to get rid of them. As for the 24px icons, I actually wasn't able to find if they are used in any of my installed applications, but they are still in the specification and they are used if the app developer chooses to use them, right?

[SmartFinn]

@morganist

As for the 24px icons, I actually wasn't able to find if they are used in any of my installed applications, but they are still in the specification and they are used if the app developer chooses to use them, right?

The 24px actions icons are often using in GTK-based DE, such as Xfce, in toolbars. However, we're talking about symbolic icons that are mostly 16px. 24px symbolic icons are using in elementaryOS, and in Xfce 4 in few places.

[SmartFinn]

@morganist

Papirus has no place for these 32px symbolic icons yet, that's why it's not so simple.

16px symbolic icons are perfectly scaled to 32px. Rules in index.theme file allow it.

[morganist]

16px symbolic icons are perfectly scaled to 32px. Rules in index.theme file allow it.

@SmartFinn Neat, but there's an issue: all of them need to be adapted, because the icons in the symbolic directory lack KDE colour scheme support. For example, there's a pending merge request with symlinks for power profiles in symbolic directiry, but I've tried it and the icons have a different colour on a panel compared to the icons from the panel directory

[SmartFinn]

@morganist could you try to add these icons without -symbolic suffix. Maybe it's the right way to add Plasma 6 support to Papirus. Like @hexchain did it in #3606 (comment)

[Erwin-Iosef]

I understand now, thank you for replying @morganist and the issue seems clear enough to me. Papirus is for all desktops not just KDE, with that I understand the design decision. Hopefully GNOME will be more flexible in the future somehow and integrate into the common standards of things. With that said I should mention I'm ignorant of why they did what they did or anything about Freedesktop spec that maybe happening for them to do this.

On the other hand, if it'll relieve some pressure off of you guys I created a fork of Papirus with the symbolics being configured for recolouring(with a script that automates changing the icons to colourable, if you need it for the future), for both Papirus and e-Papirus, anyone still facing problems with the broken colouring on KDE can use this fork or Papirus-Light/Dark, which isn't broken.

[morganist]

@Erwin-Iosef so, in your fork all symbolic GNOME icons are recolourable by KDE software stack? That means there are still no sizes between 16px and 32px, right? And by the way, did you test how GTK applications look with their icon made recolourable, especially apps that use libadwaita? I believe this information will be beneficial going forward.

[Erwin-Iosef]

I didn't look into that far, no..
I just took the code from your 16x16 icons(I tried Breeze before but then saw your code), made a script(tested as well as I could) using AI that applies the same lines without breaking anything to my knowledge, to all icons in the symbolic folder, saw that it worked on a VM on testing and called it a day. I use it on my own desktop.

But from a user's perspective that wouldn't look into such things, it worked and everything seems good. No problems so far. Of course I haven't seen anyone encountering a problem with it yet.

Maybe you could give some references on these GTK apps you're talking about? I'll be happy to test things and provide data.

[Erwin-Iosef]

<style id="current-color-scheme" type="text/css"> .ColorScheme-Text { color:#444444; } .ColorScheme-Highlight { color:#4285f4; } .ColorScheme-NeutralText { color:#ff9800; } .ColorScheme-PositiveText { color:#4caf50; } .ColorScheme-NegativeText { color:#f44336; } </style>

Basically, I applied this to every symbolic icon in the symbolic folder, with almost no error(exception being the unforseeable), watching out for and leaving strings that shouldn't be changed along the way(like the green colour in the battery icons).

[SmartFinn]

@Erwin-Iosef have you added class="ColorSheme-*" to paths elements? Adding the stylesheet doesn't change anything for the symbolic icons.

[Erwin-Iosef]

I don't really understand what you mean. How would it appear in the svg code? I'll try it out once I understand it.
EDIT: Also I opened an issue which is probably related to the recent commit.

[Erwin-Iosef]

@SmartFinn I tried your suggestion and things broke:

Result:

I tried replacing class="ColorScheme-Text" with "class="ColorScheme-*" as well but the result was the same.

[SmartFinn]

@Erwin-Iosef well, I see, you have added class="ColorScheme-Text" to the path element. That's all I wanted to know.

[Erwin-Iosef]

I see, why then tell me to add class="ColorScheme-*"?

[SmartFinn]

@Erwin-Iosef I wanted to make sure you to apply the style to the elements, and not just add the stylesheet to an icon.

[Erwin-Iosef]

Uh okay, strange.

[morganist]

@Erwin-Iosef see this file:

<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" version="1.1">
 <defs>
  <style id="current-color-scheme" type="text/css">
   .ColorScheme-Text { color:#444444; } .ColorScheme-Highlight { color:#4285f4; } .ColorScheme-NeutralText { color:#ff9800; } .ColorScheme-PositiveText { color:#4caf50; } .ColorScheme-NegativeText { color:#f44336; }
  </style>
 </defs>
 <g transform="translate(4,4)">
  <path style="fill:currentColor" class="ColorScheme-Text" d="M 3,1 V 3 H 13 V 1 Z M 2,3 C 2,3 0,3 0,5 V 13 C 0,15 2,15 2,15 H 14 C 14,15 16,15 16,13 V 5 C 16,3 14,3 14,3 V 7 L 8,10 2,7 Z M 3,5 V 7 H 13 V 5 Z"/>
 </g>
</svg>

This is an icon that's recolourable by KDE software.
Notice how there's a style element inside of <defs>, which you've added, but there's also a style attribute inside of a <path>: style="fill:currentColor" class="ColorScheme-Text". They are both crucial to make a recolourable icon

[Erwin-Iosef]

Yeah that's what I did. Here's a sample:

<?xml version="1.0" encoding="utf-8"?>
<svg height="16" version="1.1" width="16" xmlns="http://www.w3.org/2000/svg">
 <defs>
  <style id="current-color-scheme" type="text/css">
   .ColorScheme-Text { color:#444444; }
    .ColorScheme-Highlight { color:#4285f4; }
    .ColorScheme-NeutralText { color:#ff9800; }
    .ColorScheme-PositiveText { color:#4caf50; }
    .ColorScheme-NegativeText { color:#f44336; }
  </style>
 </defs>
 <path class="ColorScheme-Text" d="M 10.03,1.15 C 9.88,1.15 9.73,1.16 9.57,1.18 9,1.26 8.32,1.53 7.55,1.94 6.01,1.09 4.81,1.04 3.81,1.3 2.74,1.57 1.87,2.02 0.52,1.98 L 0,1.96 V 16 H 15 V 1.98 L 14.48,2 C 12.97,2.05 12.21,1.61 11.23,1.32 10.87,1.21 10.47,1.14 10.03,1.15 Z M 4.74,2.14 C 5.36,2.07 6.04,2.22 7,2.74 V 11.38 C 5.9,10.75 4.79,10.7 3.82,10.94 3.16,11.1 2.57,11.28 2,11.43 V 2.79 C 2.8,2.65 3.47,2.42 4.05,2.27 4.29,2.21 4.51,2.16 4.74,2.14 Z M 10.34,2.14 C 10.54,2.16 10.74,2.21 10.95,2.28 11.48,2.43 12.14,2.68 13,2.83 V 11.43 C 12.43,11.28 11.84,11.09 11.19,10.93 10.21,10.69 9.1,10.75 8,11.41 V 2.8 C 8.7,2.42 9.25,2.21 9.68,2.14 9.92,2.11 10.13,2.11 10.34,2.14 Z M 9.8,11.75 C 10.17,11.74 10.55,11.8 10.95,11.9 11.59,12.06 12.27,12.33 13,12.53 V 14 H 2 V 12.54 C 2.72,12.34 3.41,12.07 4.05,11.91 5.13,11.64 6.05,11.61 7.2,12.65 L 7.54,12.95 7.87,12.64 C 8.57,12 9.18,11.77 9.8,11.75 Z" style="fill:currentColor"/>
 <path class="ColorScheme-Text" d="M 0.94,14.75 V 12.56 L 5.16,11.43 7.5,12.03 9.89,11.36 13.63,12.36 V 14.81 Z" style="opacity:.35;fill:currentColor"/>
</svg>

[Erwin-Iosef]

I wonder if these

    .ColorScheme-Highlight { color:#4285f4; }
    .ColorScheme-NeutralText { color:#ff9800; }
    .ColorScheme-PositiveText { color:#4caf50; }
    .ColorScheme-NegativeText { color:#f44336; }

are really necessary or should be removed in the symbolic icons to optimize them.

[Erwin-Iosef]

One more thing:

Where is this white drive icon located?

[SmartFinn]

@Erwin-Iosef seems, this icon from symbolic/devices

[morganist]

@Erwin-Iosef @SmartFinn see #3923 but it can also be related to symbolic GNOME icons

[Erwin-Iosef]

@Erwin-Iosef seems, this icon from symbolic/devices

drive-harddisk-system-symbolic.svg

<?xml version="1.0" encoding="utf-8"?>
<svg height="16" version="1.1" width="16" xmlns="http://www.w3.org/2000/svg">
 <defs>
  <style id="current-color-scheme" type="text/css">
   .ColorScheme-Text { color:#444444; }
    .ColorScheme-Highlight { color:#4285f4; }
    .ColorScheme-NeutralText { color:#ff9800; }
    .ColorScheme-PositiveText { color:#4caf50; }
    .ColorScheme-NegativeText { color:#f44336; }
  </style>
 </defs>
 <path class="ColorScheme-Text" d="M 3,1 C 2,1 2,2 2,2 V 14 C 2,14 2,15 3,15 H 13 C 13,15 14,15 14,14 V 2 C 14,2 14,1 13,1 Z M 8,3 C 10.21,3 12,4.79 12,7 12,9.21 10.21,11 8,11 H 4 V 7 C 4,4.79 5.79,3 8,3 Z M 8,5 C 6.9,5 6,5.9 6,7 6,8.1 6.9,9 8,9 9.1,9 10,8.1 10,7 10,5.9 9.1,5 8,5 Z" style="fill:currentColor"/>
</svg>

[Erwin-Iosef]

Not sure if it's that but it looks correct right? I don't know why it doesn't color to dark in the xdg-desktop-portal-gtk menu.

[SmartFinn]

@Erwin-Iosef

I don't know why it doesn't color to dark in the xdg-desktop-portal-gtk menu

It because Nautilus don't change colors for symbolic icons inside browse area.

[Erwin-Iosef]

Ah damn. Meanwhile without gtk the portal looks abosolutely shite.

[ariasuni]

Not sure if that’s an already known problem, but I like to use a dark Plasma theme with a light application theme, which for Papirus means I’ll either get light back arrows (on light background) in System Settings, or dark arrows (on dark background) in Plasma systray, depending on the Papirus variant I chose to use.

[morganist]

Not sure if that’s an already known problem, but I like to use a dark Plasma theme with a light application theme, which for Papirus means I’ll either get light back arrows (on light background) in System Settings, or dark arrows (on dark background) in Plasma systray, depending on the Papirus variant I chose to use.

@ariasuni yes, that's already known. With Plasma 6, panels don't use the icons from the plasma theme and instead use them from the icon theme. The result is, you can't mix and match colour schemes without encountering bugs with Papirus because we support non-recolourable icons used in modern GNOME apps.

[markozajc]

Another missing icon is kde-symbolic, but (assuming licensing allows it), it can probably be copied from breeze-icons as-is.

[Erwin-Iosef]

I wonder if these

    .ColorScheme-Highlight { color:#4285f4; }
    .ColorScheme-NeutralText { color:#ff9800; }
    .ColorScheme-PositiveText { color:#4caf50; }
    .ColorScheme-NegativeText { color:#f44336; }

are really necessary or should be removed in the symbolic icons to optimize them.

@morganist is this set of texts necessary/good to have in the symbolic icons, apart from style=ColorschemeText in path, in making them colourable?

[morganist]

@Erwin-Iosef necessary for things such as notification dots on the system tray icons in many icons. Other colours are used more rarely, and I guess the scripts could be optimised in a way that removes these variables if they are not used in a certain icon. Not a priority, though

[Erwin-Iosef]

Ahh okay, I'll keep them in that case. It's not worth traversing each and every icon and selecting what needs it anyway.