Created attachment 196206 [details] Calc file opened under generic icon Steps: Using KDE Plasma 6.1.4 with LibreOffice 24.8.0.3 1. Right click on desktop, Create New> LibreOffice Calc, Name it and click on OK. 2. Double click on that newly created file Expected: It should be opened under Calc icon. Observed: The file is opened under LO generic icon (see attached image for more info) Info: Operating System: Manjaro Linux KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.7-3-MANJARO (64-bit) Graphics Platform: Wayland Version: 24.8.0.3 (X86_64) / LibreOffice Community Build ID: 480(Build:3) CPU threads: 2; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: en-US (en_US.UTF-8); UI: en-US 24.8.0-2 Calc: threaded
This is KDE response https://bugs.kde.org/show_bug.cgi?id=487316
FTR: the empty files are relatively new (since version 7.5), where we switched from the real ODF files (that prevent automatic creation using the current default template) to zero-byte files, that allow LibreOffice to detect that, and use the user default template to initialize such documents. See bug 139962, where that was implemented (and its pre-requisites 123476 and 139991). These empty files are not "broken", nor "bug". If there is a mechanism that LibreOffice doesn't use to set its group icon in KDE in this case, is a possible bug/enhancement in this area.
JFYI the empty files are in fact broken from the perspective of shared-mime-info, which fails to identify them properly: > $ file --mime-type ~/Desktop/foo.ods > /home/nate/Desktop/foo.ods: inode/x-empty Options include: 1. Change shared-mime-info to accept empty files as valid for these document types 2. Change LibreOffice to not go down a different codepath when opening one of these empty files in a way that manifests the bug 3. Return to using non-empty files for the templates
(In reply to Nate Graham from comment #3) > Options include: > 3. Return to using non-empty files for the templates No, 3 is not an option.
I'm just saying it's an option from a technical perspective to fix this bug. If implementing it would cause other issues, then it's not a practical option, and you're limited to #1 or #2.
(In reply to Nate Graham from comment #5) *Here* we are likely limited to #2 - because #1 is outside of LibreOffice project scope.