Bug 502681

Summary: Make creating recolorable icons simpler
Product: [Frameworks and Libraries] frameworks-kiconthemes Reporter: Ilya Fedin <fedin-ilja2010>
Component: generalAssignee: Christoph Feck <cfeck>
Status: REPORTED ---    
Severity: wishlist CC: kde, kdelibs-bugs-null, nate, notmart
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
URL: https://gitlab.freedesktop.org/xdg/default-icon-theme/-/issues/24
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Icons

Description Ilya Fedin 2025-04-11 14:34:26 UTC 
SUMMARY
Right now this requires creating a <style> tag with a CSS rule for ColorScheme classes in use and fill=currentColor in each recolorable element. GTK can recolor icons without all this, just add a class and the job done. No <style> tags, no fill=currentColor. This would make creating such icons by third parties way more appealing as they wouldn't have to think what to do when they have an already existing icons having multiple elements with different `fill` values yet logically mapping to the same ColorScheme class. It will be a one line change for each element.

STEPS TO REPRODUCE
1. Try to make a recolorable icon

OBSERVED RESULT
As easy as in GTK world

EXPECTED RESULT
Harder :(

ADDITIONAL INFORMATION
I hope this isn't a technical limitation in QtSvg or something like that... But this is a valid feature request regardless I believe.
Comment 2 Nate Graham 2025-04-11 18:21:36 UTC 
Our way supports more than 4 colors; GNOME's doesn't. Trade-offs either way, and us syncing to GNOME's thing wouldn't make sense for our use cases, any more than I suspect them syncing to ours would suit them.

Ultimately this needs to be discussed upstream and turned into a standard everyone can support. See https://gitlab.freedesktop.org/xdg/default-icon-theme/-/issues/24
Comment 3 Ilya Fedin 2025-04-12 03:23:33 UTC 
But I didn't ask to limit to 4 colors. I asked kiconthemes to add <style> tags automatically rather than icon creator. And to not to force the icon creator to set fill=currentColor (apparently by using `fill`instead of `color` in CSS rules?). GTK doesn't require icon creator to do anything of that so kiconthemes should be able to not require too.

I also don't think it has to depend on upstream discussion, recolorization is already existing while upstre discussion has stuck. If you won't do any enhancements until upstream decides something, it likely meant no enhancements possible at all.
Comment 4 Nate Graham 2025-04-16 14:25:05 UTC 
Can you supply an example of an existing KDE Icon modified to be formatted the way you'd like KIconThemes to support?
Comment 5 Ilya Fedin 2025-04-17 11:17:31 UTC 
I attempted but the result is "Your comment has been automatically blocked as it is believed to contain spam. Please contact Sysadmin if you believe this to be incorrect."
Comment 6 Nate Graham 2025-04-17 16:58:57 UTC 
Can you attach it as a file?
Comment 7 Ilya Fedin 2025-04-17 21:43:07 UTC 
Created attachment 180368 [details]
Icons

I don't know why you say "existing KDE icon" while my use-case is to add KDE recoloring support to existing non-KDE icons. Here's an example of a non-KDE icon and a edited copy, the way I would like the recoloring engine to accept it.
Comment 8 Nate Graham 2025-04-22 14:45:38 UTC 
So basically, if the icon engine saw 

> class="ColorScheme-Text"

It would replace the value of that item's fill property with the appropriate color?
Comment 9 Ilya Fedin 2025-04-22 14:49:19 UTC 
Yeah
Comment 10 Nate Graham 2025-04-23 07:19:50 UTC 
What do you think, Marco?