You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I agree to follow the Code of Conduct that this project adheres to.
I have searched the issue tracker for a feature request that matches the one I want to file, without success. There is one issue marked as a wontfix from 6 years ago, I'm hoping that's enough time for a re-request
Problem Description
Currently, Electron applications have to bundle their own icons and hardcode their path when creating a Tray object. Some allow for a choice of style (full-color vs monocrhome, light vs dark) but the icons are still from hardcoded paths. In XDG-compliant systems like Linux, applications are not expected to select their own icons, but instead use a name for the icon, that will be later searched in the user's selected icon theme, so that the style of all icons in the system tray match.
Proposed Solution
The Tray object should support being provided with both an icon name as well as an icon image, so that the name is used in platforms that support it, falling back to the specified image if the name is not supported or not found.
Alternatives Considered
An external library could implement the XDG icon lookup algorithm (given in the official XDG icon theme specification page) and be called prior to creating the Tray object to pick the icon (I'm currently in the process of finding such a library).
This has the clear disadvantage that the icon lookup has to be made by the client, who might not be able to know the expected size, format, scale, etc. of the system tray, while otherwise passing the name of the icon leaves that decision to the underlying implementation.
Additional Information
No response
The text was updated successfully, but these errors were encountered:
Preflight Checklist
Problem Description
Currently, Electron applications have to bundle their own icons and hardcode their path when creating a
Tray
object. Some allow for a choice of style (full-color vs monocrhome, light vs dark) but the icons are still from hardcoded paths. In XDG-compliant systems like Linux, applications are not expected to select their own icons, but instead use a name for the icon, that will be later searched in the user's selected icon theme, so that the style of all icons in the system tray match.Proposed Solution
The
Tray
object should support being provided with both an icon name as well as an icon image, so that the name is used in platforms that support it, falling back to the specified image if the name is not supported or not found.Alternatives Considered
An external library could implement the XDG icon lookup algorithm (given in the official XDG icon theme specification page) and be called prior to creating the
Tray
object to pick the icon (I'm currently in the process of finding such a library).This has the clear disadvantage that the icon lookup has to be made by the client, who might not be able to know the expected size, format, scale, etc. of the system tray, while otherwise passing the name of the icon leaves that decision to the underlying implementation.
Additional Information
No response
The text was updated successfully, but these errors were encountered: