https://bugs.documentfoundation.org/show_bug.cgi?id=164862

--- Comment #13 from Ivana Gyro <[email protected]> ---
I am new to here.

I(In reply to Mike Kaganski from comment #7)
> (In reply to V Stuart Foote from comment #6)
> 
> In fact, I suspect that the log will be OK, and will show the normal
> registry entries written. And that likely, "That registry value is *not*
> set" is fact refers to *only one* of the two keys that I mentioned: the
> "HKEY_CLASSES_ROOT\.ods / (Default)". And the real problem is that there is
> an override in HKCU for the value *correctly existing* in HKLM.
> 
> Some background:
> 
> 1. HKCR is not a normal registry hive, but a blend of two keys:
> 
>   * HKEY_LOCAL_MACHINE\SOFTWARE\Classes
>   * HKEY_CURRENT_USER\Software\Classes
> 
> and the entries in HKEY_CURRENT_USER take precedence. This allows a user to
> override the system-level associations; and that means, that once there is
> the user-level override, the system-level modifications will be ineffective.
> 
> This is what I suspect to happen here. Looking at
> HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ods, I expect to see that the installer
> (doing the machine-level installation) correctly updates the (Default) value
> to "LibreOffice.CalcDocument.1"; but looking at
> HKEY_CURRENT_USER\Software\Classes, we will find a ".ods" entry there, with
> an own (Default) having some other value, which is effective for the user.
> 
> And that is not a bug - it's how the system offers flexibility to its users,
> and users are free to change that - but then there's nothing we can do.
> It's, as I said, some registry change by the user (or by some of their
> actions). LibreOffice installer doesn't (and can't) make any changes to the
> user-level registry.
> 
> Indeed, that's, again, a suspicion.

I am new to here.

I confirmed on Windows 11 Home 25H2 26200.9168 the icons for ODFs are not
application specific. I ensure my extensions of odt, ods are associated with
LibreOffice.WriterDocument.1 and LibreOffice.CalcDocument.1 respectively.

I argue that we may not need to keep the verbs of ODFs to point of soffice.exe
to enable a menu icon when multi-selecting different types of ODFs. LibreOffice
points Micro Office format to module specific executable instead of
soffice.exe, which misaligns with ODFs. Additionally, Word and Excel don't
provide the same feature that displays "open", "new" and "print" items in the
menu when selecting multiple types of files.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to