Skip to content

feat(plugins): post the theme and colors into plugin iframes, and let transparency show through - #182

Merged
jherforth merged 2 commits into
jherforth:mainfrom
mrramam:feat/widget-transparency
Sep 24, 2026
Merged

jherforth merged 2 commits into
jherforth:mainfrom
mrramam:feat/widget-transparency

Conversation

@mrramam

@mrramam mrramam commented Sep 22, 2026

Copy link
Copy Markdown
Contributor

Answers #179, both halves.

Plugins never see the picked accent. A plugin's document only ever gets the static stylesheet, so interfaceColors (which live in the dashboard's browser storage) never reach it. The wrapper now posts a homeglow:theme message into each plugin frame on load and again whenever the theme or the colors change. The SDK applies it to CSS variables and exposes HomeGlow.theme and HomeGlow.onTheme() for plugins that want to react.

The guard on the new surface: the sender must be window.parent, and every value must match a hex or rgb-triplet pattern before it reaches setProperty. server/tests/pluginSdkTheme.test.js runs the SDK in a node:vm sandbox and drives 'red; background: url(x)' through the listener to assert it never lands. It also covers the parent-only check, onTheme replay and unsubscribe, and that homeglow:event still reaches on() handlers.

Transparency changed nothing visible. A widget could be marked transparent, but WidgetContainer and MobileDashboard kept painting --card-bg and the resting shadow, so the page background never showed through. Both now skip them for a transparent widget, the Admin Panel gets the setting, and the wrapper passes transparent=true to plugin frames so they match. No default was added to BASE_WIDGET_SETTINGS, since the settings tests assert exact shapes and absent already reads as false.

Two commits, kept separate: one is a plugin-platform change, the other is widget rendering.

Both have been running on our production instance since 2026-09-16 and are confirmed on a wall display. Client suite 310 passing, server 253, translation parity 790/790.

mrramam added 2 commits September 22, 2026 11:03
A plugin iframe is a separate document that only ever receives the
static stylesheet, so its --accent stayed on the file's default while
the dashboard applied the picked interface colors to its own root. The
wrapper now posts { type: 'homeglow:theme', theme, colors } into the
frame on every load and whenever the theme or colors change, over the
same parent-to-frame path the event stream uses. The SDK validates the
values (hex colors, a decimal triplet, one of the two theme names) and
writes them onto the plugin's root under the same variable names, so
CSS that reads var(--accent) follows the pick with no plugin change.
HomeGlow.theme and HomeGlow.onTheme() expose the values for canvas
drawing. Stacks on the --accent-rgb helper from the palette commit.
…gh its box

The plugin "transparent background" toggle only changed the iframe
element's own background, while the widget box behind it always painted
the card color, so both states looked the same. Widget entries now carry
`transparent`, and the dashboard box and the mobile card stop painting
the card color and the resting shadow for such a widget; the selection
border stays. Built-in widgets get the same setting, stored beside
`enabled` in widgetSettings and switched in the Admin Panel next to it.
The wrapper passes `transparent=true` on the iframe URL, which the plugin
guide has documented all along. The unused `.card.transparent-card` rule
goes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants