Proof Portal

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox

ReportR-3169GitHub issuePublicReceived

slack seems to use Xwayland by default

Reported by gammons · filed Oct 3, 2025Closed upstream on 2025-10-26 by ryanrhughes. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.

Open at source

Received and recorded verbatim. Nothing has been checked yet.

At a glance

1 · What is claimed?: Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?: Not yet mapped to any requirement or component.
3 · Is it reproducible?: No validation has been run yet.
4 · What remains unclear?: Not validated yet: no claims, no reproducer.
5 · What happens next?: Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

slack seems to use Xwayland by defaultrevision 1 · captured 2026-10-04 11:35 UTC via poll

System details

Omarchy HEAD (Oct 3 2025)

What's wrong?

Slack's Electron-based desktop application supports native Wayland rendering, but requires specific command-line flags to enable it. Without these flags, Slack runs through XWayland, which can cause blurry text on HiDPI displays and miss out on native Wayland benefits.

### Proposed Change
We might want Omarchy to add Wayland support flags to the Slack desktop entry configuration by modifying the Exec line to include:
- --enable-features=WaylandWindowDecorations - Enables native Wayland window decorations
- --ozone-platform-hint=auto - Automatically selects Wayland when available, falls back to X11

### Example Configuration
Create/modify ~/.local/share/applications/slack.desktop:

  [Desktop Entry]
  Name=Slack
  StartupWMClass=Slack
  Comment=Slack Desktop
  GenericName=Slack Client for Linux
  Exec=/usr/bin/slack --enable-features=WaylandWindowDecorations --ozone-platform-hint=auto --gtk-version=3 -s %U
  Icon=slack
  Type=Application
  StartupNotify=true
  Categories=GNOME;GTK;Network;InstantMessaging;
  MimeType=x-scheme-handler/slack;

  Benefits
  - Native Wayland rendering (no XWayland translation layer)
  - Crisp text rendering on HiDPI displays
  - Better performance and lower latency
  - Proper Wayland window management

View raw text

### System details

Omarchy HEAD (Oct 3 2025)

### What's wrong?

Slack's Electron-based desktop application supports native Wayland rendering, but requires specific command-line flags to enable it. Without these flags, Slack runs through XWayland, which can cause blurry text on HiDPI displays and miss out on native Wayland benefits.

  ### Proposed Change
We might want Omarchy to add Wayland support flags to the Slack desktop entry configuration by modifying the `Exec` line to include:
  - `--enable-features=WaylandWindowDecorations` - Enables native Wayland window decorations
  - `--ozone-platform-hint=auto` - Automatically selects Wayland when available, falls back to X11

  ### Example Configuration
 Create/modify `~/.local/share/applications/slack.desktop`:
  ```desktop
  [Desktop Entry]
  Name=Slack
  StartupWMClass=Slack
  Comment=Slack Desktop
  GenericName=Slack Client for Linux
  Exec=/usr/bin/slack --enable-features=WaylandWindowDecorations --ozone-platform-hint=auto --gtk-version=3 -s %U
  Icon=slack
  Type=Application
  StartupNotify=true
  Categories=GNOME;GTK;Network;InstantMessaging;
  MimeType=x-scheme-handler/slack;

  Benefits
  - Native Wayland rendering (no XWayland translation layer)
  - Crisp text rendering on HiDPI displays
  - Better performance and lower latency
  - Proper Wayland window management

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

No decision has been recorded yet.

Proof

History & reports

Reference