Research: can the COSMIC panel stay visible while the drop-down is open?

Date: 2026-10-01 Question: Is it possible for DropTerm to make the panel visible while the dropdown terminal is open?

TL;DR

Yes — a small code change, no compositor changes. The drop-down covers the panel today only because DropTerm asks for exclusive_zone = -1 when shown (src/app.rs:734). Per the wlr-layer-shell protocol, -1 means “do not move me to accommodate other surfaces; extend me all the way to my anchored edges.” If the shown surface instead requests exclusive_zone = 0, the compositor (cosmic-comp, via Smithay’s layer map) places it inside the usable area — directly below a top-edge panel’s reserved strip — leaving the panel visible and clickable. This works on the Overlay layer, so the drop-down stays above fullscreen windows, which is the app’s headline behavior. Recommended shape: keep -1 as the default and put 0 behind a config knob (e.g. respect_panel), since both behaviors are legitimate preferences for a quake-style terminal.

There is no config-only path: switching layer to Top alone does not help, because the -1 zone still overlaps the panel’s strip (and Top loses to focused fullscreen windows).

What DropTerm does today

Findings

1. The protocol: zone 0 vs -1 is exactly this choice

wlr-layer-shell-unstable-v1, zwlr_layer_surface_v1.set_exclusive_zone (rendered from the protocol XML at https://wayland.app/protocols/wlr-layer-shell-unstable-v1):

“Surfaces that do not wish to have an exclusive zone may instead specify how they should interact with surfaces that do. If set to zero, the surface indicates that it would like to be moved to avoid occluding surfaces with a positive exclusive zone. If set to -1, the surface indicates that it would not like to be moved to accommodate for other surfaces, and the compositor should extend it all the way to the edges it is anchored to.” … “For example, a panel might set its exclusive zone to 10 … A notification might set its exclusive zone to 0, so that it is moved to avoid occluding the panel … A wallpaper or lock screen might set their exclusive zone to -1, so that they stretch below or over the panel. The default value is 0.”

The spec’s “notification” example is precisely DropTerm’s situation. Also from the spec: layers are ordered background < bottom < top < overlay, “ordering within a single layer is undefined”, and fullscreen shell surfaces are only “typically” at the top layer — layer/zone are independent knobs.

2. Smithay: where cosmic-comp actually implements placement

cosmic-comp’s layer-shell handler is a thin shim — new_layer_surface pushes a PendingLayer, later mapped via Smithay’s LayerMap::map_layer (cosmic-comp src/wayland/handlers/layer_shell.rs, src/shell/mod.rs map_layer L3066-3089). The placement algorithm is LayerMap::arrange in Smithay/smithay src/desktop/wayland/layer.rs:

So a zone-0 (“Neutral”) surface is laid out inside the area that survives after the panel took its strip — regardless of whether the surface is on the Top or the Overlay layer. Placement is re-run on every commit: cosmic-comp src/wayland/handlers/compositor.rs L372 calls layer_map_for_output(&output).arrange(), so a runtime set_exclusive_zone re-arranges the surface live, no remap needed.

3. cosmic-panel: what the panel asks for

From pop-os/cosmic-panel (master, checked out 2026-10-01):

4. cosmic-comp: how overlap-notify feeds the panel’s intellihide

OverlapNotifyState::refresh (src/wayland/protocols/overlap_notify.rs L80-165) intersects each subscribed layer surface (the panel) with (a) toplevels on active workspaces or sticky, and (b) other layer surfaces (add_layer). The panel client handles those events in cosmic-panel-bin/src/xdg_shell_wrapper/client/handlers/overlap.rs L99-106.

Consequence for DropTerm: with today’s zone -1, an open drop-down geometrically intersects the panel and is reported as a layer overlap (panel reflows content if intellihide is on). With zone 0 there is no intersection at all, so nothing is reported — the panel is simply untouched.

5. cosmic-comp: stacking and keyboard focus (the trade-offs)

From src/shell/focus/order.rs (render_input_order, the canonical z-order walk):

Keyboard focus, verbatim comment in src/shell/focus/mod.rs (~L655-660):

“If an exclusive layer shell surface exists (on any output), only exclusive shell surfaces can have focus, on the highest layer with exclusive surfaces. Popups are judged by their root surface, so an exclusive surface can still open grabbing popups (menus, dropdowns, context menus).”

So while DropTerm holds KeyboardInteractivity::Exclusive, panel popovers cannot take keyboard focus (panel is on Top, DropTerm’s exclusive surface is on Overlay). Pointer input is geometric and unaffected: panel buttons remain clickable next to an open drop-down. This is arguably desirable for a quake terminal (keys go to the shell), but users who want to type into panel popovers while the terminal is open would need keyboard_mode: OnDemand, which already exists as a config option.

6. libcosmic plumbing (DropTerm’s pinned rev 08a09e3)

Verified in the local checkout (~/.cargo/git/checkouts/libcosmic-41009aea1d72760b/08a09e3/, i.e. pop-os/libcosmic @ 08a09e3):

7. Prior art: cosmic-ext-quake-terminal

cosmic-ext-quake-terminal is not a layer-shell app: src/wayland.rs drives a regular cosmic-term toplevel via cosmic_client_toolkit toplevel-info/toplevel-management (minimize/activate). It is the “minimize/restore window trick” DropTerm’s README explicitly avoids, so it has no layer/exclusive-zone decision to compare. As a normal window it appears in Alt-Tab, and — fun asymmetry — the panel’s intellihide would react to it, because it counts as a toplevel overlap.

Options for DropTerm

Option Change Panel visible? Above fullscreen? Notes
A. zone 0 when shown (recommended) src/app.rs:734: set_exclusive_zone(id, 0) ✅ sits flush below panel strip (top edge) or above dock (bottom edge) ✅ stays on Overlay height_percent keeps meaning “share of usable area” (the measuring surface already measures the usable area)
B. config-only layer: Top none ❌ still overlaps panel (zone stays -1) ❌ loses to focused fullscreen Rejected — doesn’t achieve the goal
C. config knob for A new field (e.g. respect_panel: bool, default false) → zone 0 when set ✅ opt-in ✅ Best of both worlds; false preserves current Yakuake-like cover behavior

Details worth knowing for option A/C:

What would change in the code (descriptive, not a patch)

Unverified / open questions

Sources

Improve this page on GitHub