Skip to content

fix(engines): find LibreOffice where its Windows installer recorded it - #719

Merged
KnifeLemon merged 1 commit into
mainfrom
fix/libreoffice-registry-detect
Oct 28, 2026
Merged

KnifeLemon merged 1 commit into
mainfrom
fix/libreoffice-registry-detect

Conversation

@KnifeLemon

Copy link
Copy Markdown
Owner

What does this change?

On Windows, Filee found an installed LibreOffice only on the PATH and in Program Files\LibreOffice\program. A copy installed on another drive (D:\LibreOffice) or in a folder of its own had to be picked by hand with Use my copy….

LibreOffice's installer records its program folder as the default value of SOFTWARE\LibreOffice\UNO\InstallPath. Filee now reads that key, for this user and for all users, in the 64-bit and 32-bit views, after the PATH and before the Program Files guess. A missing key or one Filee can't read is skipped.

Raised in discussion #671.

Type of change

  • Bug fix
  • New feature or improvement
  • New format or engine
  • Translation
  • Documentation
  • Build, CI or dependencies

How was it tested?

  • dotnet format --verify-no-changes on the changed files
  • dotnet test for SystemCopyTests and OwnCopyTests (Windows): the new test writes the key under HKCU\Software\FileeTests, with the path in quotes as installers sometimes write it, and checks that the folder is read back and holds soffice.exe; a missing key gives nothing. The key is removed afterwards.
  • Tried it with a real LibreOffice on another drive: no LibreOffice on this PC.

Checklist

  • No new UI strings
  • No new third-party code or binaries
  • The PR does one thing

🤖 Generated with Claude Code

On Windows, LibreOffice was found only on the PATH and in Program Files, so
a copy installed on another drive or in a folder of its own had to be picked
by hand (Use my copy…). Its installer records the program folder as the
default value of SOFTWARE\LibreOffice\UNO\InstallPath; that key is now read
for this user and for all users, in the 64-bit and 32-bit views, after the
PATH and before the Program Files guess.

Refs discussion #671

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions github-actions Bot added the bug Something isn't working label Oct 28, 2026
@KnifeLemon
KnifeLemon merged commit 6b26c0e into main Oct 28, 2026
16 of 17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant