### System details

2012 MBP i7 4 GB RAM

### What's wrong?

## Metadata

* **Date:** 2026-08-31
* **Component:** `hyprland` (`/usr/share/omarchy/default/hypr/apps/system.lua`, window rules) / `libreoffice`
* **Severity:** Medium
* **Reproducibility:** Intermittent / Backend- and State-dependent (Portal readiness & Geometry cache)
* **Status:** Untersucht (Investigated & Documented)
* **Upstream Issue / PR:** Not submitted yet (Ready for upstream submission)

---

## System Environment

* **Distribution:** Omarchy Quattro
* **Version:** 4.0.2 (`/usr/share/omarchy/version`)
* **Desktop / Compositor:** Hyprland (Wayland) + Omarchy Shell (Top bar layer surface)
* **Application:** LibreOffice Fresh / LibreOffice Writer / Calc (`libreoffice-fresh`)

---

## Problem Description

When attempting to open or save a document in LibreOffice (e.g. `File` -> `Open...` or `File` -> `Save As...`), the file selector dialog expands to fill the entire monitor height.

Because the Omarchy top bar is rendered as an overlay layer surface, the file dialog slides directly *underneath* the top bar. Consequently, the top row / title bar and header navigation buttons of the file picker dialog are cut off and obscured by the top bar.

---

## Reproducibility & Backend Variations

> [!NOTE]
> Why this bug appears intermittently depending on desktop session state:

1. **XDG Portal vs. Native/VCL Dialogs:**
   - When the XDG Desktop Portal (`xdg-desktop-portal-gtk`) handles the file dialog, Omarchy's existing rule in `system.lua` (`o.window("xdg-desktop-portal-gtk", { tag = "+floating-window" })`) catches it and renders it properly.
   - However, if the portal service is not yet fully ready (e.g. right after login), if LibreOffice falls back to its built-in VCL dialog, or if "Use LibreOffice dialogs" is active in LibreOffice settings, the window class is `soffice.bin` or `libreoffice-*`.
   - These classes are **not** covered by Omarchy's current window rules in `system.lua`.
2. **Window Geometry Caching:**
   - Once a dialog is manually moved or resized during a session, LibreOffice or the compositor may cache the geometry for subsequent opens in the same session, temporarily masking the unmanaged full-height bug.

---

## Steps to Reproduce

1. Open LibreOffice Writer or Calc.
2. Ensure LibreOffice falls back to internal dialog or launch before portal hook binds (or test with `SAL_USE_VCLPLUGIN=gen` or LibreOffice internal dialogs).
3. Click `File` -> `Open...` (or press `Ctrl+O`).
4. Observe the unconstrained file picker window geometry.
5. Notice that the window spans the full height of the display, extending behind the top panel bar.
6. Notice that the top control row / breadcrumbs / title area of the dialog is partially or completely covered by the top bar.

---

## Expected Behavior

File picker and dialog windows should:
1. Open as centered floating windows with sensible dimensions (matching the standard `floating-window` size in Omarchy, e.g., `875x600`), OR
2. Respect the workspace/exclusive zone margins so that no part of the dialog window is hidden underneath the top bar under any fallback condition.

---

## Actual Behavior

The LibreOffice file selector window is not constrained by floating dialog rules in fallback scenarios, expands to 100% monitor height, and is clipped by the top bar.

---

## Technical Context & Root Cause Analysis

### Root Cause
In `/usr/share/omarchy/default/hypr/apps/system.lua`, dialog floating rules explicitly restrict target window classes to only a small subset:

```lua
-- Current rule in /usr/share/omarchy/default/hypr/apps/system.lua:
o.window({
  class = "(sublime_text|DesktopEditors|org.gnome.Nautilus)",
  title = "^(Open.*Files?|Open [F|f]older.*|Save.*Files?|Save.*As|Save|All Files|.*wants to [open|save].*|[C|c]hoose.*)",
}, { tag = "+floating-window" })
```

LibreOffice windows (which use window classes such as `soffice.bin`, `libreoffice-writer`, `libreoffice-calc`, etc.) are not included in this class pattern. Therefore:
- The dialog is not tagged as `+floating-window`.
- It misses the standard centered floating layout (`size = { 875, 600 }`, `center = true`).
- It defaults to unconstrained window sizing which overlaps with layer surfaces.

---

## Proposed Fix

### Option 1: Expand Class Regex in `apps/system.lua`
Extend the class matching list to include LibreOffice binary and app identifiers:
```lua
o.window({
  class = "(sublime_text|DesktopEditors|org.gnome.Nautilus|soffice|soffice.bin|libreoffice.*)",
  title = "^(Open.*Files?|Open [F|f]older.*|Save.*Files?|Save.*As|Save|All Files|.*wants to [open|save].*|[C|c]hoose.*)",
}, { tag = "+floating-window" })
```

### Option 2: Dedicated LibreOffice App Rule File
Create `/usr/share/omarchy/default/hypr/apps/libreoffice.lua`:
```lua
o.window({
  class = "^(soffice|soffice.bin|libreoffice.*)$",
  title = "^(Open.*|Save.*|Confirm.*|Properties.*|Options.*)$",
}, { tag = "+floating-window" })
```

### Option 3: Force XDG Portal Integration for LibreOffice
Ensure LibreOffice consistently uses the GTK3 / XDG Desktop Portal file picker backend by setting `SAL_USE_VCLPLUGIN=gtk3` and `GTK_USE_PORTAL=1` in the environment.