Skip to content

Add common Linux editor open targets #309

Open
ohnicholas93 wants to merge 2 commits into
ilysenko:mainfrom
ohnicholas93:feat/linux-open-editor-destinations
Open

Add common Linux editor open targets #309
ohnicholas93 wants to merge 2 commits into
ilysenko:mainfrom
ohnicholas93:feat/linux-open-editor-destinations

Conversation

@ohnicholas93
Copy link
Copy Markdown
Contributor

Summary

  • add Linux editor open targets for Cursor, VS Code, VS Code Insiders, Windsurf, Antigravity, and Zed
  • detect editors from PATH first, then matching .desktop entries including AppImage, Flatpak, Snap, and XDG application directories
  • launch desktop-entry backed editors through the desktop launcher path so wrapped Flatpak/AppImage installs work instead of invoking wrapper binaries directly

User-visible behavior

Linux users should see supported installed editors in the Open in... destination list instead of only File Manager. This improves common installs where the editor is exposed through a desktop entry rather than a plain PATH binary, such as Cursor AppImage and Zed Flatpak installs.

Scope notes

This stays in the core Linux compatibility patch because these editor destinations mirror upstream desktop open-target behavior and are Linux port glue, not an opt-in extra feature. The change is limited to the main-process patch and its targeted regression tests.

Validation

  • node --test scripts/patch-linux-window-ui.test.js
  • node --test linux-features/zed-opener/test.js linux-features/open-target-discovery/test.js
  • git diff --check

Note

This overlaps with the linux-features/zed-opener use case by adding common upstream editor targets to the core Linux path. I’m happy to adjust the scope if maintainers prefer this to remain opt-in.

@ilysenko
Copy link
Copy Markdown
Owner

Thanks for the PR. I like the direction, but I do not want this to live in the core main-process patch.

Please move all of this out of scripts/patches/main-process.js and into linux-features. We already have linux-features/open-target-discovery, which is probably the right home for most of this work: it is disabled by default and already covers Linux editor / terminal / desktop-entry discovery. If that feature does not fit cleanly, a new disabled-by-default feature is also fine.

The core applyLinuxFileManagerPatch should stay focused on the minimal File Manager compatibility path only. This PR currently adds broad editor discovery and launching logic there: Cursor, VS Code, VS Code Insiders, Windsurf, Antigravity, Zed, PATH lookup, .desktop parsing, XDG / Flatpak / Snap directories, and gio / gtk-launch launching. That is useful optional Linux UX, but it should not be enabled for every Linux build by default.

Please also move the new regression coverage into the feature-level test suite, and keep a test proving the feature is disabled unless explicitly listed in linux-features/features.json.

Happy to review again once the change is isolated as an opt-in Linux feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants