### System details

Omarchy 4.0.2-1 on intel i5,

### What's wrong?

Report created using crush with glm5.3-flash as backend

### Versions
  - Hyprland 0.56.2 (commit efb50993780079460b0cbed1363e2166a2de1d9f)
  - hyprland-guiutils 0.2.2
  - Arch Linux, Wayland, NVIDIA proprietary driver
  - Monitor scale 1.25 (fractional)
  - Relevant env: `QT_QPA_PLATFORM=wayland;xcb`, `QT_QPA_PLATFORMTHEME=gtk3`, `QT_IM_MODULE=fcitx`

  ### Bug 1: `--text` is not rendered (reproducible)

  **Steps to reproduce:**
  ```bash
  hyprland-dialog --title "Test title" --text "This message should be visible" --buttons "OK;Cancel"
```

  **Observed:** the big title and the right-aligned buttons paint, but the entire   message area is empty — uniform background pixels, no text, no placeholders.

  **Verified by pixel analysis** (screenshot via `grim` of the exact window   geometry, decoded and counted): only two non-background bands exist — a ~280 px   centered title band and a right-aligned button band. The central region where   the message should be is 100% background color. A dialog spawned by Hyprland   itself ("Application Not Responding", `--text "An application Hermes - Hermes   is not responding. What do you want to do with it?" --buttons Terminate;Wait`)   shows the identical result: title + buttons painted, message area empty.

  Also noticed: the Wayland window title stays empty in `hyprctl clients`   (`title:`, `initialTitle:`) even though `--title` was passed.

  ### Bug 2: ANR dialogs can hang forever, unresponsive and uncloseable

  **Context:** an Electron app (Chromium main-thread abort) hung repeatedly.   Each hang triggered an "Application Not Responding" dialog. Observed over one   morning:

  - Three dialogs spawned; two remained alive ~19 h / ~3.5 h **after their target     process had already died** (targets were killed by a crash, cores in
    `systemd-coredump`). Orphaned dialogs are never dismissed.
  - Duplicates stack pixel-identical at the same position (two dialogs both at     the same `at:`/`size:` in `hyprctl clients`), so it looks like one broken popup.   - The two stuck dialogs were completely unresponsive: Terminate/Wait clicks did     nothing, no close button, not killable via the GUI.

  **Evidence (limited — ptrace was blocked by yama, so no userspace backtrace):**   - `/proc/<pid>/task/*/wchan` for both stuck dialogs: **all 13 threads on     `futex_do_wait`**, including the main thread.
  - A freshly spawned, healthy `hyprland-dialog` at the same time: main thread in     `poll_schedule_timeout` (normal Qt event loop), rest on futexes.
  - Stuck dialogs had consumed ~no CPU (not a busy loop) — consistent with a     deadlock, e.g. a synchronous wait.
  - `SIGTERM` from a terminal terminated them cleanly; windows were then gone.

  So: whatever Hyprland's ANR flow uses to drive/wait on the dialog can wedge   the dialog's event loop, and there is no timeout, no orphan cleanup, and no   GUI escape hatch.

  ### Suggestions
  1. Fix `--text` rendering (suspect interaction of fractional scaling and/or      `QT_QPA_PLATFORMTHEME=gtk3`; happy to test patches or more env combos).   2. ANR flow: don't wait on the dialog synchronously; auto-dismiss the dialog      when the hung PID exits; add a timeout; don't spawn duplicates at the same      coordinates; make the dialog closeable.