3.8 KiB
Prompt 1
Map the complete current state of XFCE Wayland support as of October 2026. Cover official roadmap (wiki.xfce.org/releng/wayland_roadmap), xfwl4 status (gitlab.xfce.org/xfce/xfwl4, FAQ, blog posts by Brian Tarricone / Alexxcon), preview releases (first ~June 2026, 4.21.1 August 2026), component-by-component Wayland readiness table, what still requires external compositors (labwc/wayfire), remaining gaps vs X11/xfwm4, and any community ports (e.g. hanthor/xfce-wayland). List exact missing features, known bugs, and the official target of feature parity without dropping X11 support.
Prompt 2
Produce a precise feature-parity matrix between xfwm4 (X11) and current xfwl4 (Wayland/Smithay). For every major xfwm4 capability (window decoration, stacking, workspaces, keyboard shortcuts, mouse/touchpad settings, screen margins, session restore, multi-monitor, compositor effects, accessibility, NVIDIA handling, etc.), state current xfwl4 status (implemented / partial / missing), the relevant Wayland protocol or Smithay primitive required, and the exact code or issue tracker references. Identify the largest remaining gaps that prevent a seamless user experience.
Prompt 3
Deep technical analysis of xfwl4 architecture. Explain how it uses Smithay, the current session root model (why the compositor must become the session root instead of xfce4-session), support for xdg-session-management, XWayland integration status, layer-shell usage for panel/desktop, and the planned reuse of existing xfconf settings and xfwm4 dialogs. List all required runtime and build dependencies, meson/Rust CI changes still needed, and the exact remaining work to reach the “behaves like xfwm4” goal stated in the FAQ.
Prompt 4
Break the remaining XFCE-to-Wayland work into the “diverse large but simple steps” required for a complete, production-quality port. Define sequential phases (e.g. Phase A: stabilize core compositor + basic window management; Phase B: full settings dialogs and workspaces; Phase C: panel plugin isolation and desktop integration; Phase D: power/keyboard/session parity; Phase E: packaging, dual-session polish, edge-case elimination). For each phase list concrete deliverables, dependencies, estimated complexity, and acceptance criteria that eliminate caveats.
Prompt 5
Detail every remaining protocol and integration gap. Cover workspaces (ext-workspace / wlr-workspace), foreign toplevel management, idle-notify, output power management, layer-shell, xdg-session-management, embedding/compositor capabilities for panel plugins, and any missing keyboard/mouse/brightness handling that currently lives only inside the compositor. For each, specify the exact Wayland protocol status, current xfwl4/Smithay support, required changes in xfce4-panel, xfdesktop, xfce4-settings, xfce4-power-manager, and the minimal code changes needed.
Prompt 6
Generate a complete, zero-caveat migration and dual-support plan. How to keep xfwm4 fully functional on X11 indefinitely, how to make xfwl4 the default Wayland path while preserving identical user-visible behavior (same config dialogs, same xfconf keys, same shortcuts), how session startup changes, how to handle NVIDIA and non-wlroots edge cases, packaging for major distributions, and a testing matrix that guarantees no regressions for existing X11 users and a polished Wayland experience.
Prompt 7
Produce the concrete implementation checklist and verification steps that would allow someone to claim a perfect result. List every remaining open issue from the xfwl4 tracker and roadmap, the exact order of large simple steps to close them, how to validate feature parity (side-by-side X11 vs Wayland sessions), required documentation updates, and the final acceptance criteria that match the promise of “perfect result without caveats.” Include build, runtime, and user-level tests.