Bug 164311 - Windows installation does not add "App Paths" entries
Summary: Windows installation does not add "App Paths" entries
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
24.8.3.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Installer-Windows
  Show dependency treegraph
 
Reported: 2024-12-12 23:10 UTC by Eyal Rozenberg
Modified: 2024-12-16 10:34 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2024-12-12 23:10:48 UTC
Windows supports adding aliases base-filename-like aliases for full paths of executables, so that when you Start > Run, you can type in the app paths entry name and run the associated application. 

See an explanation of this here:
https://helgeklein.com/blog/how-the-app-paths-registry-key-makes-windows-both-faster-and-safer/

for example.

Now, it seems LibreOffice does not add any App Paths entries, or at least - not ones I think it should add. Those are:

Certainly:

* writer.exe
* impress.exe
* base.exe
* libreoffice.exe
* draw.exe

Possibly:

* loffice.exe
* soffice.exe
* calc.exe
* scalc.exe
* swriter.exe
* simpress.exe
* sdraw.exe
* localc.exe
* loimpress.exe
* lobase.exe
* lowriter.exe

(calc is tricky because there's Microsoft built-in calculator, also named calc)
Comment 1 V Stuart Foote 2024-12-13 00:37:57 UTC
Oh, no no no!

Already too many pitfall in Windows registry.

If you want the aliases, as an expert user--just add them yourself (trivial).

We do not need to complicate the Windows MSI packaging and QA challenges with this anti-feature.

-1
Comment 2 V Stuart Foote 2024-12-13 00:47:21 UTC
And actually, we do already lay down the appropriate and expected launchers.

For a admin install for all users
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

sbase.exe
scalc.exe
sdraw.exe
simpress.exe
smath.exe
soffice.exe
switer.exe


But it is trivial per user to establish their own launcher as they like with entries in
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

Beyond the that list, see NO reason to provide additional launcher alias to our as built launchers.
Comment 3 Mike Kaganski 2024-12-13 07:52:13 UTC
(In reply to Eyal Rozenberg from comment #0)
> Certainly:
> 
> * writer.exe
> * impress.exe
> * base.exe
> * libreoffice.exe
> * draw.exe

I agree with WONTFIX. We create the *correct* app paths. We must not create any additional potential clashes, by claiming executable names we don't have.
Comment 4 Heiko Tietze 2024-12-13 09:17:36 UTC
=> NAB

Ultimately no UX topic
Comment 5 Mike Kaganski 2024-12-13 09:34:15 UTC
(In reply to Heiko Tietze from comment #4)
> Ultimately no UX topic

I believe, that the original UX request was because it's currently impossible on Windows to hit <WinKey>+R (a shortcut for shell's "Run"), type "writer", press Enter, and have Writer launched. The same works, if one types "swriter".
Comment 6 Eyal Rozenberg 2024-12-13 10:57:12 UTC
(In reply to V Stuart Foote from comment #2)
> And actually, we do already lay down the appropriate and expected launchers.

But these are not appropriate and expected from the user's perspective. The user should not be a student of history, remembering that once, LO Writer was StarWriter, and the executable would therefore be named swriter, or soffice etc.
Comment 7 Mike Kaganski 2024-12-13 11:09:17 UTC
(In reply to Eyal Rozenberg from comment #6)

You yourself have identified the problem with calc. It is already the reason why the name conflicts are a thing to beware. Using command line is not a basic user level UI; knowing the executable names is not something for intuition.

Until we really use other executable names, we should not claim them. That's simply confusing. Note also, that this doesn't work e.g. in cmd.exe; so the usefulness of this confusing MS feature (the whole of it) is questionable (it is inconsistent on the OS level).
Comment 8 Mike Kaganski 2024-12-13 11:12:05 UTC
> this doesn't work e.g. in cmd.exe

... meaning that simple "swriter" won't work. Of course, there is a way to make it work there using "start swriter", piling complexities and inconsistencies.