Repository navigation
Roadmap: in development, to do, backlog, done #161
Description
Living tracker, updated as work moves. Move items between sections by editing this issue.
In development
- Native Wayland host for Uno (fixes Fix: Pixelated text and glitching icons (top-left icon) #113 properly). Fork: MemerGamer/uno
- 6.7 bridge (
wayland/host) with full X11-host parity: EGL + wl_shm rendering with sharp fractional scaling, multiple outputs, pointer/keyboard (xkbcommon, dead keys and Compose, cursor shapes), clipboard and drag & drop, text-input-v3 IME (tested with fcitx5 + mozc), portal file pickers, client-side decorations for GNOME, window states and activation - Bridge packages released: uno-wayland-6.7.135-wayland.5 (used by 0.1.0-alpha6; wayland.4 shipped in alpha5 via Feature: Use the native Wayland host by default on Linux #186)
- Smooth resizing (configures paced by presented frames, full-frame damage while resizing), native-like text coverage (no Skia luminance gamma), released in wayland.5
- Fork CI: every PR commit builds on its own with Uno's style checks; full runtime suite under headless Weston next to Xvfb (11,425 tests per host, 0 Wayland-only failures)
- Uno's 8-reviewer review panel and repeated cross-model reviews addressed; final review round fixed
- PR branch on the latest Uno master, adapted to Uno's new host-owned renderer API: per-commit CI green, 0 Wayland-only failures in the full suite
- wayland.5 text-coverage and frame-skip fixes ported into the PR stack (
wayland/pr, 17 commits): per-commit CI green, full suite with no regressions against X11. Hinting/LCD from fontconfig and full-frame damage on resize stay follow-ups - PR opened and ready for review: feat(wayland): Add a native Wayland host for Skia desktop unoplatform/uno#25503 (tracking Wayland support unoplatform/uno#17600), rebased on current master, full AI-assistance disclosure
- Screenshots attached to the PR
- Maintainer review
- 6.7 bridge (
To do (alpha9)
- Offer the LCD text and X11 drag-and-drop work to Uno as follow-up PRs once feat(wayland): Add a native Wayland host for Skia desktop unoplatform/uno#25503 has been reviewed
- Release notes page: render the LinuxFiles GitHub release Markdown instead of the fallback
- Nix: add mpv and WebKitGTK to the flake so previews work on NixOS
- Drops from other apps: Files moves within the same drive even when the source asked for a copy (Windows behaviour); decide whether to honour the source's requested action
- Verify the light-theme toolbar focus fix from Fix: Light-theme toolbar focus and column header contrast #169 (could not reproduce the original problem)
- Review and merge the macOS contribution (@lextm plans a cross-platform enablement PR first, then the macOS code; macOS CI build on GitHub runners requested). Prep done: Linux-only code mapped, the Wayland package switch is scoped to Linux targets so a macOS target stays on stock Uno packages
Backlog
- Interactive HTML previews (WPE WebKit through an Uno WebView add-in, about 2-3k lines; see docs/linux-port/wayland-previews.md)
- Rename the project if macOS ships (keep
LinuxFilesuntil then; app-ID migration needed) - Bring Windows back once Linux runs well on Wayland (Windows CI, platform code behind
Files.Platform.Abstractions), long-term goal: one code base for all platforms - Cherry-pick useful upstream Files changes selectively (docs/linux-port/upstream-policy.md)
Done
- 0.1.0-alpha8 released: sharper subpixel (LCD) text, real audio/video (libmpv) and sandboxed HTML previews on Wayland and X11 (Feature: Play media and render HTML in the preview pane on Wayland #198), X11 drag and drop with other apps in both directions (Feature: Prepare dragging files to other apps through Uno's X11 drag source #197); Uno packages wayland.7; release PR Release 0.1.0-alpha8 #199
- GitHub release
- AUR
linuxfiles-binupdate - Nix flake (Code Quality: Update the Nix flake to 0.1.0-alpha8 #200)
- Wayland drag-and-drop source added to feat(wayland): Add a native Wayland host for Skia desktop unoplatform/uno#25503 (3 commits, now 20 in total): per-commit CI green, full suite 0 Wayland-only failures
- 0.1.0-alpha7 released: drag files from LinuxFiles into other Wayland apps (Uno wayland.6, Feature: Drag files from LinuxFiles into other apps on Wayland #194), incoming drops get file paths, Wayland preview fallbacks for HTML/media/release notes (Fix: Fixed an issue where HTML and media previews were blank on Wayland #192), Cards rename fix (Fix: Fixed an issue where renaming in the Cards layout showed a black box #193); release PR Feature: Release 0.1.0-alpha7 with Wayland drag-and-drop to other apps #195
- GitHub release
- AUR
linuxfiles-binupdate - Nix flake (Code Quality: Update the Nix flake to 0.1.0-alpha7 #196)
- 0.1.0-alpha6 released: smoother Wayland resizing, sharper text and native-size theme icons (Fix: Fixed an issue where file and folder icons looked low-res at 100% scale #189, Feature: Release 0.1.0-alpha6 with smoother Wayland resizing and sharper text and icons #190); Uno packages wayland.5
- GitHub release
- AUR
linuxfiles-binupdate - Nix flake (Code Quality: Update the Nix flake to 0.1.0-alpha6 #191)
- 0.1.0-alpha5 released (GitHub, AUR, Nix): first release with the native Wayland host by default (Feature: Use the native Wayland host by default on Linux #186, Feature: Release 0.1.0-alpha5 with the native Wayland host by default #187, Feature: Update the Nix flake to 0.1.0-alpha5 #188)
- 0.1.0-alpha4 released (GitHub, AUR, Nix); earlier alphas 1-3
- Native Wayland host by default on Linux (Feature: Use the native Wayland host by default on Linux #186): forked Uno 6.7.135-wayland.4 packages from a fork release, pinned by SHA-256; X11 fallback at runtime,
-p:UseUnoWayland=falseopt-out. Shipped in 0.1.0-alpha5 - README and NOTICE now state that Files and LinuxFiles are MIT with some MPL-2.0 files (Fix: README and NOTICE now mention MPL-2.0 files alongside MIT #185, reported by a Files maintainer)
- Going up a folder selects the folder you came from again (Fix: Select the folder you came from when navigating up on Linux #184, thanks @lextm)
- Security review (Code Quality: Security review report (docs only) #174) and fixes, all 10 findings closed: archive extraction confined to the destination with an openat2 fallback (Fix: Confine archive extraction and merge to the destination (R2) #177); Open With uses spec-correct argv, no shell (Fix: Open With no longer expands filenames into shell code (R1) #176); trash hardening (Fix: Empty Trash symlink and trash metadata hardening (R3, R8) #178); cross-device moves never delete changed sources (Fix: Do not delete originals that changed during cross-device move (R4) #179, Fix: Never delete a move source that changed after it was copied #182); P2/P3 hardening (Fix: Security P2/P3 hardening (R5-R7, R9, R10) #180)
- Faster startup, bounded D-Bus waits, theme watcher retries (Fix: Faster startup, bounded D-Bus waits #175)
- Tags follow files on rename/move (Fix: Tags follow files on rename and move #164, Fix: Tags follow files on cross-device moves again #181), "Invalid item" dialog guard (Fix: Suppress spurious Invalid item dialog on restored sessions #165)
- Root-mode environment keep-list and installer paths (Fix: Root-mode environment keep-list and installer paths #166); faster select-all (Fix: Faster select-all on large folders #167); compositor scale detection for niri/sway/Hyprland/KDE/GNOME (Fix: More robust compositor scale detection #168)
- Visual fixes: column header contrast (Fix: Light-theme toolbar focus and column header contrast #169), context menu smear + Properties backdrop (Fix: Context menu acrylic smear and Properties dialog backdrop #170), single-line file names (Fix: Long file names end with an ellipsis in Details #171)
- Independent fork: Windows code, projects, CI and upstream sync removed (Code Quality: Detach from upstream Files (stage 1: remove Windows projects, CI, sync) #159, Code Quality: Strip WINDOWS preprocessor branches (stage 2) #160, Code Quality: Remove residual Windows remnants #172); README, CONTRIBUTING, changelog (Code Quality: README, CONTRIBUTING and changelog for the independent fork #173)
- Wayland spike (Code Quality: Wayland host spike report (#113) #163), Debian 13 "2 s per action" not reproducible (Performance: Debian 13 KDE takes about 2 seconds per action #131)
- Upstream Files v4.3 merged (Code Quality: Sync upstream Files (2026-10-12) #158) before going independent
Activity
lextm commentedon Oct 12, 2026
Thanks for all the work on bringing Files to Linux.
After seeing #159 and #160, I'm curious about your long-term vision. Is removing Windows support and stopping upstream synchronization just a temporary decision to prioritize Linux, or do you intend to maintain LinuxFiles as a permanently independent fork?
I don't think cross-platform support requires migrating the Windows version to Uno. Files can continue shipping its Windows version with WinUI 3 / Windows App SDK, while Linux and macOS use Uno Platform. They can share much of the application code, with platform-specific implementations where necessary.
Given how extensively AI-assisted development is already being used here, I would expect preserving Windows compatibility and keeping up with upstream to be more manageable than before. The Windows implementation already exists, and maintaining compatibility seems more sustainable than allowing the codebases to diverge completely.
I've also been working on a macOS port and was considering contributing it here. However, my intention isn't to maintain a separate macOS fork in the long run. I'd rather work toward a shared codebase where Windows, Linux, and macOS changes are kept synchronized, with the ultimate goal of merging the cross-platform work back into files-community/Files.
Of course, that would require coordination with upstream, and I fully understand that Linux may remain the immediate priority. But I believe preserving Windows compatibility and the possibility of upstream integration is important for the long-term sustainability of this effort.
Would you be interested in pursuing that direction?
MemerGamer commentedon Oct 13, 2026
Thanks for the thoughtful comment, and for the offer! I agree with the end goal: one code base that runs on Windows, Linux and macOS, ideally something files-community/Files could use one day.
Dropping Windows was a practical call for now: day to day I can only build and test on Linux, and keeping Windows code I can't test, plus the daily upstream merges, was costing more than it gave. The current focus is making the Linux version really solid, including a native Wayland host that we're contributing to Uno upstream (unoplatform/uno#17600).
Once Linux runs well on Wayland, I'd like to bring Windows back properly: Windows CI and the platform code restored behind the same platform layer the Linux code uses (
Files.Platform.Abstractions/Files.Platform.Linux).A macOS port would be very welcome here, as its own platform project next to the Linux one. Small, focused PRs would be easiest to review. If you open an issue with what you have so far, we can work out where the platform boundaries need to change for macOS. And if files-community ever shows interest in a cross-platform version, I'd be happy to coordinate.
lextm commentedon Oct 13, 2026
Indeed, the Linux port is more challenging as you are likely to hit more issues than me on macOS.
I think one way to reduce the noise from the Windows side is that we stick to major releases such as 4.2 and 4.3, ignoring patch releases such as 4.2.x. That means infrequent rebase/merge every 2-3 months, which an AI tool can help complete within just a couple of hours.
I plan to create a pull request with cross-platform enablement added first, so that your Linux port can be prepared in advance. You can review it at any pace, while I move the macOS port forward. Once that's merged, I will send a second pull request to include all macOS code.
Once macOS/Linux support ships from a single repo, we can align with Files Windows v4.3 or v4.4 depending on the timeline and coordinate with the upstream on the final merge.
MemerGamer commentedon Oct 13, 2026
Sounds good, a cross-platform enablement PR first and then macOS makes sense. Feel free to open it whenever it's ready and we can discuss the details there. For this phase I'd like to keep Windows projects and
#if WINDOWScode out; Windows comes back as its own step later.On syncing: since #159/#160 stripped the Windows code, merging upstream releases would now conflict wherever upstream touches code we removed, so for now we cherry-pick individual upstream fixes. Once Windows support returns, syncing at major releases like you describe sounds like the right cadence.
For macOS: I can't test it locally, so a macOS CI build on GitHub runners as part of that PR would help a lot, and I'll rely on you for runtime testing there. Coordinating with files-community can come once both platforms ship from here.