https://bugs.kde.org/show_bug.cgi?id=494086
--- Comment #5 from graham.ke...@gmail.com <graham.ke...@gmail.com> --- I debugged this further, and I think the GTK fix is working correctly; the issue is now in breeze-icons. Here is the situation: After Nate's fix in GTK, GTK looks for the following icons for the spinbox decrease button, in this order: 1. value-decrease-symbolic (explicit) 2. list-remove-symbolic (explicit) My understanding is that if it doesn't find either of those, it will eventually start looking for the non-symbolic versions of those icons, by chopping off the last term in the name: 3. value-decrease 4. list-remove I wasn't actually able to check this non-symbolic fallback behavior. It seems to fall back to some other icons first, including alternate-size versions of 1 and 2, if those are available in the theme. I am noting this because I saw it in my debugging, but I don't think it's causing an immediate issue. What is relevant is that if icon #1 is not found, it looks for icon #2 before checking for the non-symbolic versions. The reason for the issue is that breeze-icons 6.11.0 provides these three icons: - actions/16/value-decrease.svg - actions/16/list-remove.svg - actions/16/list-remove-symbolic.svg (symlinked to list-remove) There is no value-decrease-symbolic icon included. So when value-decrease-symbolic isn't found, the next icon in order is list-remove-symbolic, which is present, and therefore we get the "X" icon instead of the "-" icon. I think the best solution is to symlink value-decrease-symbolic.svg to value-decrease.svg, at least for the 16px size. Probably also worth doing for 22px; I don't know what uses that icon size but the same -symbolic discrepancy exists there. I'd be happy to submit a merge request to fix this if I my proposal seems reasonable? -- You are receiving this mail because: You are watching all bug changes.
