Why COSMIC-style Applets Need a Rendering Boundary

I investigated whether Glimpse could host COSMIC-style applets and found that launching them was the easy part. The hard boundary was rendering: an external Wayland client owns its surfaces, while a GTK panel owns its widget tree. Process supervision does not make one embeddable inside the other.

This remains a design investigation, not a shipped Glimpse feature. The architecture became clearer when I stopped treating a complete embedding implementation as if it were already within reach.

COSMIC passes a display connection, not a GTK widget

COSMIC applets are separate processes launched from desktop entries. The panel creates a Wayland socket pair, passes the applet one end through WAYLAND_SOCKET, and composites the surfaces the applet creates. The current 1 source shows the environment and file-descriptor handoff directly.

Glimpse's existing executable applet protocol has a different ownership model. An external process sends JSON describing widgets and actions, then Glimpse renders native GTK widgets. That is easy to lay out beside built-in modules because the shell owns every pixel.

A COSMIC-style applet sends a Wayland surface. GTK 4 does not provide a general operation that appends an arbitrary foreign Wayland surface to a gtk::Box. A host must participate at the compositor level, translate input and focus, position popups, and decide what happens when either process exits.

The first complete design was too large

One possible answer was a custom host that treated every external applet as a surface tree. That would require enough compositor behavior to place the main surface, handle popups and subsurfaces, route pointer and keyboard input, manage focus, and apply shell effects. It was technically coherent and far too large for the feature being requested.

The narrower design split the applet into two surfaces of responsibility. Glimpse would keep rendering a small indicator through its existing widget protocol. The external applet could own the richer popover content on a private Wayland display, while Glimpse owned placement, stacking, blur, focus, and closing behavior.

This hybrid is not free. The two sides still need a protocol for status, actions, popover registration, sizing, and lifecycle. It does, however, give each side a boundary it can actually enforce: the applet owns its content, and the shell owns desktop policy.

Ownership is the architectural question

Plugin discussions often begin with discovery formats, manifests, and subprocess APIs. Those are useful only after deciding who owns rendering. If the host renders a declarative model, integration is constrained but native. If the plugin renders pixels, the host needs a surface protocol and compositor responsibilities. Mixing the models without naming the boundary produces a system where focus, accessibility, theming, and failure recovery belong to nobody.

The COSMIC investigation ruled out the deceptively easy version of this feature. Supporting another applet ecosystem is not mainly a matter of parsing its desktop files. A viable implementation needs an explicit rendering boundary, and the smallest credible version is likely a hybrid rather than a general foreign-surface container.