noticenterctl talks to the UnixNotis control plane over D-Bus.

Two command families are local-only and do not depend on D-Bus:

• css-check
• preset ...

# Open and close the panel
noticenterctl open-panel
noticenterctl close-panel

# Toggle DND
noticenterctl dnd toggle

# Clear all notifications
noticenterctl clear

Workspace usage:

cargo run --release -p noticenterctl -- open-panel

• toggle-panel
• open-panel [--debug <level>] where level is critical|warn|info|verbose
• close-panel
• dnd <on|off|toggle>
• clear
• dismiss <id>
• list-active [--full]
• list-history [--full]
• inhibit <reason> [--scope <all|popups>]
• uninhibit <id>
• list-inhibitors
• css-check
• preset export <name.unixnotis> [--except <path> ...] [--force]
• preset inspect <name.unixnotis>
• preset import <name.unixnotis> [--except <path> ...] [--dry-run] [--allow-exec]

open-panel --debug enables panel debug logging for the current session:

UNIXNOTIS_DIAGNOSTIC=1 noticenterctl open-panel --debug verbose

For panel-open performance work, UNIXNOTIS_PERF_PROBE=1 can be added to the same command. See the Performance wiki page for the profiling workflow.

The --full flag emits summaries and bodies when diagnostic mode is enabled. The output stays single-line safe for terminal use, so control characters are stripped:

UNIXNOTIS_DIAGNOSTIC=1 noticenterctl list-active --full

# Suppress popups while a fullscreen app is running
TOKEN=$(noticenterctl inhibit "presentation" --scope popups)

# Later, re-enable popups
noticenterctl uninhibit "$TOKEN"

# Inspect current inhibitors
noticenterctl list-inhibitors

css-check follows the active theme files from config.toml:

• [theme].base_css
• [theme].panel_css
• [theme].popup_css
• [theme].widgets_css
• [theme].media_css

It validates those files the same way the live UI loads them. Relative theme paths resolve from $XDG_CONFIG_HOME/unixnotis (or $HOME/.config/unixnotis when XDG is unset), but absolute paths and non-.css file names are also allowed and are checked too.

The output is a grouped report instead of a flat log stream. The default order is:

• css-check summary
• diagnostic categories
• active theme files
• notes
• errors
• warnings
• css-check result: clean|warnings found|failed

Warnings and errors are grouped by file. Lint warnings include line and column information when the source location is reliable, which makes duplicate selectors, duplicate properties, and GTK layout-value issues easier to track down.

When stdout is a real terminal, css-check also colors section headers and result lines:

• errors in red
• warnings in yellow
• notes in cyan
• clean results in green

Pipes, redirected output, NO_COLOR, CLICOLOR=0, and TERM=dumb stay plain text.

Checks include:

• GTK parse errors
• duplicate selectors and duplicate properties, including nested @media, @supports, @layer, @container, and @document blocks
• unsupported or risky GTK size expressions, especially percentage-based layout values and size rules the geometry model cannot safely resolve
• missing theme target files
• multiple theme slots that resolve to the same file
• extra .css files under the config tree that are not referenced by config.toml
• panel runtime floor warnings
• width-pressure warnings for toggle grids, stat grids, card grids, and media rows
• complex tracked UnixNotis selectors that carry width or padding rules the geometry model cannot fully map
• descendant selectors aimed at GTK subnodes stay quiet, while descendant selectors whose final target is a UnixNotis hook still warn

Use css-check for both theme syntax mistakes and config/path mistakes. Modern GTK CSS is supported when the syntax is valid for the active runtime.

noticenterctl css-check

Example warning output:

css-check summary
  root: $HOME/.config/unixnotis
  checked: 5 files
  errors: 0
  warnings: 3

diagnostic categories
  lint: 3

active theme files
  [theme].base_css    -> $HOME/.config/unixnotis/base.css
  [theme].panel_css   -> $HOME/.config/unixnotis/panel.css
  [theme].popup_css   -> $HOME/.config/unixnotis/popup.css
  [theme].widgets_css -> $HOME/.config/unixnotis/widgets.css
  [theme].media_css   -> $HOME/.config/unixnotis/media.css

warnings

  $HOME/.config/unixnotis/widgets.css (1)
    lint: line 214, col 1: duplicate selector '.unixnotis-info-icon'

css-check result: warnings found

UnixNotis can export, inspect, and import a full setup as a single .unixnotis bundle file.

Export the current setup:

noticenterctl preset export name.unixnotis

Inspect a bundle before importing:

noticenterctl preset inspect name.unixnotis

Preview an import without writing files:

noticenterctl preset import name.unixnotis --dry-run

Import for real:

noticenterctl preset import name.unixnotis

Keep a local file during import:

noticenterctl preset import name.unixnotis --except widgets.css

Skip files during export:

noticenterctl preset export name.unixnotis \
  --except installer.toml \
  --except assets/preview.png

Preset commands also do extra validation:

• export blocks outside theme paths and outside explicit command paths
• export can rewrite host-specific command paths in the bundled config.toml
• import blocks path traversal and config-root escapes
• import warns when bundled CSS asset refs leave the config root or use remote URLs
• import pauses for an executable-content review when the bundle carries commands or scripts
• import creates backups for overwritten files
• import runs css-check after a real import

Interactive import behavior for executable content:

• if the bundle contains command-bearing config fields or bundled scripts, import warns before any write starts
• Inspect executable content now? opens a pager using $PAGER or less
• the review page shows the runnable config slots and bundled script payloads
• leaving the pager does not approve the import by itself
• Import this preset anyway? is the final trust decision

Non-interactive imports fail closed on executable content unless --allow-exec is passed.

For a full workflow guide, see Presets.

• D-Bus API reference: D-Bus-API
• Preset workflow guide: Presets