Problem
A plugin's .page Icon can be a font glyph or a static image. Glyph icons adapt to the active theme automatically: they render as <b class="fa fa-... system"> and inherit the theme text color. Image icons do not. A .png renders as a static <img class="system">, so a full-color logo can look wrong on some themes (a dark logo disappears on the black theme, a light logo washes out on the white theme).
Today the only theme-adaptive option for an image is a single-color inline SVG using currentColor, which forces the logo to be monochrome and loses its real colors.
Request
Let a plugin provide a light and a dark logo variant that the webgui switches based on the active theme, the same way glyph icons already adapt. This lets plugin authors ship proper full-color logos that look right on every theme.
Where it stands today
The icon is rendered per type, for example in plugins/dynamix/include/DefaultPageLayout/Navigation/Main.php:
$icon = $button['Icon'];
if (substr($icon, -4) == '.png') {
$icon = "<img src='/{$button['root']}/icons/$icon' class='system'>"; // static image
} elseif (substr($icon, 0, 5) == 'icon-') {
$icon = "<b class='$icon system'></b>"; // Unraid glyph, theme-aware
} else {
$icon = "<b class='fa fa-$icon system'></b>"; // FontAwesome, theme-aware
}
The same .png -> <img> pattern also appears in the dashboard tiles, the sidebar-theme icon CSS, the settings/tools tiles, and the plugin page header.
Proposed mechanism (backward compatible)
Two options, whichever you prefer:
- A) Naming convention: alongside
icon.png, an optional icon-dark.png. If the dark variant exists, render both and let CSS pick the right one per theme. No manifest change.
- B) A new optional
.page field, for example IconDark=icon-dark.png, for an explicit second variant.
In both cases: dark themes show the light logo, light themes show the dark logo. No variant present means the single image renders exactly as today, and glyph icons are unchanged.
The switch can reuse the existing theme classes, for example:
.icon-theme-dark { display: none; }
.Theme--black .icon-theme-light { display: none; }
.Theme--black .icon-theme-dark { display: inline; }
Open questions for maintainers
- Preferred mechanism: naming convention (A) or a new field (B)?
- Which themes count as dark (black, azure)?
- Should this also cover SVG icons and the sidebar-theme icon path?
Happy to open a PR once the mechanism and the dark-theme set are confirmed.
Environment
- Unraid 7.x webgui (dynamix)
Problem
A plugin's
.pageIconcan be a font glyph or a static image. Glyph icons adapt to the active theme automatically: they render as<b class="fa fa-... system">and inherit the theme text color. Image icons do not. A.pngrenders as a static<img class="system">, so a full-color logo can look wrong on some themes (a dark logo disappears on the black theme, a light logo washes out on the white theme).Today the only theme-adaptive option for an image is a single-color inline SVG using
currentColor, which forces the logo to be monochrome and loses its real colors.Request
Let a plugin provide a light and a dark logo variant that the webgui switches based on the active theme, the same way glyph icons already adapt. This lets plugin authors ship proper full-color logos that look right on every theme.
Where it stands today
The icon is rendered per type, for example in
plugins/dynamix/include/DefaultPageLayout/Navigation/Main.php:The same
.png -> <img>pattern also appears in the dashboard tiles, the sidebar-theme icon CSS, the settings/tools tiles, and the plugin page header.Proposed mechanism (backward compatible)
Two options, whichever you prefer:
icon.png, an optionalicon-dark.png. If the dark variant exists, render both and let CSS pick the right one per theme. No manifest change..pagefield, for exampleIconDark=icon-dark.png, for an explicit second variant.In both cases: dark themes show the light logo, light themes show the dark logo. No variant present means the single image renders exactly as today, and glyph icons are unchanged.
The switch can reuse the existing theme classes, for example:
Open questions for maintainers
Happy to open a PR once the mechanism and the dark-theme set are confirmed.
Environment