Bug 487026

Summary: Use symbolic icons for systray app if present
Product: [Plasma] plasmashell Reporter: Christian (Fuchs) <kde>
Component: XembedSNIProxyAssignee: Plasma Bugs List <plasma-bugs>
Status: CLOSED FIXED    
Severity: wishlist CC: 4wy78uwh, akontsevich, kde, materka, nate, notmart
Priority: NOR    
Version: 6.0.4   
Target Milestone: 1.0   
Platform: Other   
OS: Linux   
URL: https://invent.kde.org/plasma/plasma-desktop/-/issues/142#note_1107473
See Also: https://bugs.kde.org/show_bug.cgi?id=499825
Latest Commit: Version Fixed In: 6.2.0
Sentry Crash Report:

Description Christian (Fuchs) 2024-05-14 16:27:23 UTC
SUMMARY
As per a discussion in the VDG group: 
I propose adding either an option  (or, as per Nate, just a new default) of using the -symbolic icon for an app, if present.

Usecase: have icon themes / apps that want to support it by shipping a -symbolic icon to follow our usually monochrome icons in systray.

Logic would basically be: when loading an icon, check if there is a -symbolic suffixed version of that icon for that size, if yes: use that, if no: use the requested icon.

Argument against hardcoding it: would override apps explicit wishes.
Argument against an option: it's an option, and it might not always work, thus give users wrong expectations if not clearly worded  (e.g. should be [ ] use monochrome icon if available, not [ ] use monochrome icon)
Comment 1 Nate Graham 2024-08-06 21:07:33 UTC
This makes sense, we should just do it. It's harmless since if no such icon exists, it will fall back to simpler names until it finds something that does exist.
Comment 2 David Edmundson 2024-10-16 21:41:43 UTC
We don't have control of the drawing with xembedsniproxy.
Comment 3 Nate Graham 2024-10-16 21:58:49 UTC
We don't have control over the pixmap drawing, but we can append "-symbolic" to the icon name that it gets, for apps that send an icon name instead of or in addition to a pixmap. I interpreted this bug report to be requesting that.
Comment 4 Bug Janitor Service 2024-10-24 10:05:54 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4865
Comment 5 Marco Martin 2024-10-24 10:08:43 UTC
made a mr for it.

if an application really, really wants to use a custom drawn icon with the system not changing it, it can always send only a pixmap and not an icon name, which seems the case for instance of Telegram unless one specifically checks for "use monochrome icons" in the telegram settings
Comment 6 Bug Janitor Service 2024-10-29 09:00:06 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4878
Comment 7 Marco Martin 2024-10-29 09:42:04 UTC
Git commit fe5794a038e4bcf719e4fa243f1f337521b04727 by Marco Martin.
Committed on 29/10/2024 at 09:42.
Pushed by mart into branch 'master'.

applets/systemtray: Prefer -symbolic icons

append -symbolic to icon names in the custom icon loading mechanism in
the systemtray

This won't adress XEmbed-sniproxy icons and won't address also icons that only send a pixmap instead of an icon name, but those are cases we can't do anything about

alternative to https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4865

M  +4    -1    applets/systemtray/statusnotifieritemsource.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/fe5794a038e4bcf719e4fa243f1f337521b04727
Comment 8 Aleksey Kontsevich 2025-02-11 13:37:13 UTC
I do not like this behaviour: I like standard colorful icons in the system tray.  I want coulorful icons everywhere@ Coudl we have the choice please???!!! If it is possible for Kickoff, why not for the systemtray as well?!

https://kde.org/ru/announcements/plasma/6/6.3.0/
> In Plasma 6.2, we introduced symbolic icons in Kickoff’s category sidebar. 
> Some people didn’t like that, so in 6.3 you can undo the change yourself: 
> we modified the implementation to pull icons from the standard data source, 
> allowing you to set them to whatever you want using the Menu Editor app.

Related issues and discussions:
- https://bugs.kde.org/show_bug.cgi?id=486752
- https://bugs.kde.org/show_bug.cgi?id=457077
Comment 9 Roke Julian Lockhart Beedell 2025-02-11 14:23:56 UTC
(In reply to Aleksey Kontsevich from comment #8)
You shouldn't unilaterally reopen issues merely because you've the permission to. That's the role of the triage owner and assignee. I suggest you file a feature request requesting this, and then link that here.
Comment 10 Nate Graham 2025-02-11 14:27:49 UTC
What you're asking for was already implemented in Plasma 6.3; you can now control the icons to your liking using KMenuEdit. See https://invent.kde.org/plasma/plasma-desktop/-/issues/142#note_1107473

As RJLB said, please don't re-open closed bug reports.
Comment 11 Christian (Fuchs) 2025-02-11 14:28:58 UTC
(In reply to Nate Graham from comment #10)
> What you're asking for was already implemented in Plasma 6.3; you can now
> control the icons to your liking using KMenuEdit. See
> https://invent.kde.org/plasma/plasma-desktop/-/issues/142#note_1107473

No, they just used that as a reference, they talk about having _the same_ in the systray. 
So it is not implemented. 

But yes, it should be a new bug report, that is correct.
Comment 12 Nate Graham 2025-02-11 16:22:47 UTC
Oh my mistake!

That said, I don't see us making it optional for the System Tray too. The System Tray has been trying to use symbolic icons for over a decade; this isn't new.
Comment 13 Aleksey Kontsevich 2025-02-11 16:54:15 UTC
(In reply to Christian (Fuchs) from comment #11)
> (In reply to Nate Graham from comment #10)
> > What you're asking for was already implemented in Plasma 6.3; you can now
> > control the icons to your liking using KMenuEdit. See
> > https://invent.kde.org/plasma/plasma-desktop/-/issues/142#note_1107473
> 
> No, they just used that as a reference, they talk about having _the same_ in
> the systray. 
> So it is not implemented. 
> 
> But yes, it should be a new bug report, that is correct.

I'll create one. Who to CC on it?
Comment 14 Aleksey Kontsevich 2025-02-11 17:10:08 UTC
(In reply to Roke Julian Lockhart Beedell from comment #9)
> (In reply to Aleksey Kontsevich from comment #8)
> You shouldn't unilaterally reopen issues merely because you've the
> permission to. That's the role of the triage owner and assignee. I suggest
> you file a feature request requesting this, and then link that here.

https://bugs.kde.org/show_bug.cgi?id=499825