The need
Today, all dashboard widgets are developed in the core of Gladys. An integration (especially an external one, via the SDK) cannot propose a widget specific to its domain, although this is often where the data makes the most sense: solar production tracking, status of a robot vacuum, charging schedule of an electric car, etc.
The proposal
Allow an integration to declare one or more widgets via a JSON schema, on the same principle as the configuration pages of external integrations. The integration describes what to display (values, graphs, buttons, states, gauges…), and it’s Gladys that decides how to display it.
Deliberately, no custom HTML or iframe: it’s a philosophical choice. By remaining declarative, the core of Gladys ensures for all widgets, including third-party ones: visual consistency, dark mode, mobile/tablet responsiveness, translations, performance, and non-regression when the interface evolves. It’s the same model as iOS widgets: purely declarative, and no one finds the ecosystem lacking in richness 
The benefits
- Integrations become complete: their data finally have a real place on the dashboard
- The experience remains clean and unified, regardless of the widget’s author
- The JSON being validatable, an AI will be able to generate or repair these widgets reliably (and eventually, build an entire dashboard on demand)
- The vocabulary of components can be gradually enriched in the core, without ever breaking anything, and each addition benefits all integrations at once
Areas for reflection
- Define the initial vocabulary: what basic components? (value + unit, historical graph, action button, list of states…)
- How the widget retrieves its data: existing device features, or endpoint exposed by the integration?
- Version the schema so that widgets remain compatible with updates
