I’ve been extending Desktop Icons NG (GTK4 port) to support a desktop widget system.
Current widget set:
-
clock
-
weather (Open-Meteo)
-
system metrics (libgtop / UPower)
-
sticky notes
-
calendar (EDS)
-
media player (MPRIS)
Widgets are implemented as GTK4-based hosts embedding WebKitGTK WebViews, and are integrated with the desktop layer. Each widget can be toggled per-instance between:
-
desktop mode (pinned to monitor, below windows)
-
floating mode (above all windows)
The toggle switches window type/stacking (DESKTOP ↔ DOCK/ABOVE), so the same widget can act as either a passive desktop surface or an always-on-top utility.
HTML widget model
The system is designed to make widget authoring simple:
-
UI written in HTML/CSS/JS
-
no GNOME/GTK knowledge required
-
small manifest (
widget.json) defines metadata + defaults -
each widget runs inside a confined
ding-widget://sandbox
A lightweight JS bridge (window.ding) provides:
-
config get/set
-
host state (selection, edit mode, etc.)
-
messaging to the host
Why WebKitGTK
WebKitGTK was chosen to:
-
lower the barrier to entry (web stack is widely familiar)
-
allow fast iteration and richer UI
-
isolate widgets using a custom URI scheme + CSP
-
reuse a shared WebContext for efficiency across widgets
Widgets can optionally use a per-instance backend subprocess (JSON IPC over stdin/stdout) for system access, keeping the frontend render-focused.
Architecture highlights
-
GTK4 + libadwaita host
-
WebKitGTK WebView per widget
-
ding-widget://per-instance sandbox -
optional backend subprocess per widget
-
per-monitor placement (not global desktop state)
-
event-driven updates (EDS, MPRIS, system metrics)
Extension:
https://extensions.gnome.org/extension/5263/gtk4-desktop-icons-ng-ding/
Repo:
https://gitlab.com/smedius/gtk4-ding
I realize icons and widgets on GNOME can be controversial. This is entirely opt-in, and I’m mainly looking for feedback—especially around layering semantics, UX expectations, and the widget authoring model.
