## Summary

GTK file-picker dialogs opened through `xdg-desktop-portal-gtk` are **tiled** instead of floated whenever the requesting application's app-id becomes the dialog's Wayland class. Because the dialog then inherits the *requesting app's* class, Omarchy's portal floating rule (which matches `class = xdg-desktop-portal-gtk`) never fires. The dialog is tiled at its natural (tiny) size, which clips or hides its bottom action row — so the confirm button (e.g. **"Open" / "Öffnen"**) is unreachable or disappears entirely in fullscreen tile mode.

Concrete app where this bites: **RapidRAW** (`rapidraw-bin`, GPU-accelerated RAW editor), but the bug is generic to any GTK app whose portal dialogs inherit the app class.

## Environment

- Omarchy: **4.0.4-1**
- Hyprland: **0.56.2**
- Kernel: 7.1.13-3-2-ARCH (aarch64)
- Hardware: Apple MacBook Pro 17,1 (M1, Asahi Linux), GPU `agx-t8103` / `asahi`
- Portal: `xdg-desktop-portal-gtk` (also `xdg-desktop-portal-hyprland` present)

## Steps to reproduce

1. Open **RapidRAW** (or any GTK app that opens a folder/file picker via the portal).
2. On the home screen, choose to open a folder → the "Select Folder" portal dialog opens.
3. Observe the dialog is **tiled** (not floating/centered). The bottom action bar with the confirm button is clipped.
4. Make the tile fullscreen → the confirm button disappears entirely. It cannot be clicked in tiled mode.

## Expected behavior

Portal file-picker dialogs float, are centered, and show their full action row (which is exactly what Omarchy's existing rule intends for `xdg-desktop-portal-gtk`).

## Root cause

`/usr/share/omarchy/default/hypr/apps/system.lua` has:

```lua
o.window("xdg-desktop-portal-gtk", { tag = "+floating-window" })
```

This matches the window **class** against `xdg-desktop-portal-gtk`. However, on Wayland the GTK portal dialog inherits the requesting application's app-id, so the class reported to Hyprland is the app's class — not the portal's. Verified with `hyprctl clients -j`:

```
class = 'RapidRAW', initialClass = 'RapidRAW', initialTitle = 'Select Folder',
title = 'Select Folder', pid = 29734, floating = False, size = [306, 174]
```

The requesting process pid (`29734`) is `/usr/bin/RapidRAW`, and the dialog is served by `xdg-desktop-portal-gtk` (pid 1454), but the window class is `RapidRAW`. The rule's class matcher therefore never matches, and the dialog falls through to the default tiled layout.

## Suggested fix

Match portal file dialogs by title pattern in addition to the portal class, so the rule covers dialogs that inherit the requesting app's class. E.g. in `apps/system.lua`:

```lua
-- Portal dialogs that inherit the requesting app's class (e.g. RapidRAW's GTK
-- folder picker reports class "RapidRAW"): float by title pattern too.
o.window(
  {
    title = "^(Select Folder|Open [F|f]older.*|Open.*Files?|Save.*Files?|Save.*As|Save|All Files|.*[Cc]hoose.*|.*wants to [open|save].*)$",
  },
  { tag = "+floating-window" }
)
```

(or extend the existing `class = "(sublime_text|DesktopEditors|org.gnome.Nautilus)"` title rule, which has the same intent but a hard-coded class list).

## Local workaround (already applied on the affected machine)

Added to `~/.config/hypr/hyprland.lua`:

```lua
o.window(
  {
    class = "^RapidRAW$",
    title = "^(Select Folder|Open [F|f]older.*|Open.*Files?|Save.*Files?|Save.*As|Save|All Files|.*[Cc]hoose.*|.*wants to [open|save].*)$",
  },
  { tag = "+floating-window" }
)
```

With this rule the dialog floats, is centered, and the confirm button is clickable. `hyprctl reload` + `hyprctl configerrors` are clean.

## Diagnostics

`omarchy-debug --no-sudo --print` output is attached (also written to `/tmp/omarchy-debug.log`). Key entries: Omarchy 4.0.4-1, Hyprland 0.56.2, Apple MacBook Pro 17,1 (aarch64), and `rapidraw-bin 1.6.5-1 (AUR)`.