I cannot reproduce this on stock Fedora 41, nor on Plasma master. Both when opening two different LibreOffice applications from the menu or when opening the files from Dolphin, there are two separate task manager entries for Writer and Calc documents. Their application name is also shown correctly, not as soffice.bin.

Can you try creating a new user account to see if this still happens? Which VCL are you using in libreoffice? Are you launching the default Fedora .desktop files for libreoffice or do you have custom ones?

Indeed, after looking a bit at my installation, I can confirm that the bug comes from my own configuration of libreoffice, and not from the task manager.

As a workaround to a bug where LibreOffice in Wayland mode does not scale properly on multi-monitor setup with different dpi, I use the alias `/usr/.local/bin/libreoffice` with:
```
#!/bin/bash
WAYLAND_DISPLAY= SAL_USE_VCLPLUGIN=kf6 QT_AUTO_SCREEN_SCALE_FACTOR=1 /usr/bin/libreoffice "$@"
```
which forces LibreOffice to use x11 with the kf6 VCL. 
The .desktop files are the default ones.

When removing the `WAYLAND_DISPLAY=`, LibreOffice reuses wayland and groups properly in the taskbar, but the multi-monitor with different dpi scaling bug reappears.

However, even when running in x11 mode, the grouping should work, based on the WM_CLASS declared in the .desktop I guess.
Using `xprop | grep WM_CLASS` command on my x11 LibreOffice window, I get `WM_CLASS(STRING) = "soffice.bin", "soffice.bin"`, but should it rather be "libreoffice-calc" "LibreOffice Calc" ?. In the .desktop file (/usr/share/applications/libreoffice-calc.desktop), I have `StartupWMClass=libreoffice-calc`.

Taking another x11 application, for example Spotify, I get `WM_CLASS(STRING) = "spotify", "Spotify"` which here is correct.

Well, I am not sure I understand well how WM_CLASS works, so the problem might also come from elsewhere.

> However, even when running in x11 mode, the grouping should work, based on the WM_CLASS declared in the .desktop I guess.
Using `xprop | grep WM_CLASS` command on my x11 LibreOffice window, I get `WM_CLASS(STRING) = "soffice.bin", "soffice.bin"`, but should it rather be "libreoffice-calc" "LibreOffice Calc" ?. In the .desktop file (/usr/share/applications/libreoffice-calc.desktop), I have `StartupWMClass=libreoffice-calc`.

No, StartupWMClass does not *set* the startup wm class for that window - the application itself sets the window class, and most (in particular Qt and gtk applications) should also allow you to set the WMClass as a launch parameter. The primary purpose of the StartupWMClass field according to the desktop file specification is for mapping launch notifications via the startup notification spec - if a window with that wmclass appears, it's an indication for that spec that the application launch is complete and any user feedback about this may stop (such as the bouncing icon, or the task manager indicator with the swirly circle). 

https://specifications.freedesktop.org/desktop-entry-spec/latest/recognized-keys.html

https://specifications.freedesktop.org/startup-notification-spec/0.2/ 

It might also be used to match windows and .desktop files, but I'm not sure about that and don't think it is from some testing I did a while ago, or this might only be used on X11 (I only tested it on Wayland) or as a fallback if the regular methods fail).

As I understand it, the applications report which .desktop file they belong to, and the task manager uses this information directly to match windows to .desktop files (and thus know which windows to group as tasks, and which not). This is completely within the purview of the the application itself. So it would seem that LibreOffice in the particular combination of settings that you have takes a code path that does not set the relevant property correctly.

https://nicolasfella.de/posts/importance-of-desktop-file-mapping/

I suspect that this is a LibreOffice bug, especially if the mapping works correctly in the default configuration. Or it might be an intended conseequence of the environmental setting you've set, I haven't read the documentation on what exactly that is supposed to do.

You can, however, set the matching desktop file using a KWin Rule - setting the corresponding .dektop file is one of the KWin properties, and you can use WMClass or window title etc. to override the default assignment and set your own preferred .desktop file (I've helped someone in the past set up separate browser task manager entries depending on particular launch configurations). Though in this case, it would seem to me that this is just working around an application or kwin bug that should be fixed.

Hm, reading what you're doing exactly again, try setting your environment variable modifications in the desktop file (create a copy in ~/.local/share/applications, or have the menu editor do it for you). It might be that the intervening shell script is interfering with the heuristic that maps applications and desktop files.

Keeping my alias /usr/local/bin/libreoffice to set up the environment variables like this:
```
#!/bin/bash
env <env_variables> /usr/bin/libreoffice "$@"
```
I tested different <env_variables> configurations:
1. With xwayland:
- QT_QPA_PLATFORM=xcb SAL_USE_VCLPLUGIN=gtk3: Task bar grouping works, scaling in multiple display and different dpi works.
- WAYLAND_DISPLAY= SAL_USE_VCLPLUGIN=gtk3: Task bar grouping does not work, scaling in multiple display and different dpi works.
- QT_QPA_PLATFORM=xcb SAL_USE_VCLPLUGIN=kf6: Task bar grouping does not work, scaling in multiple display and different dpi works.
- WAYLAND_DISPLAY= SAL_USE_VCLPLUGIN=kf6: Task bar grouping does not work, scaling in multiple display and different dpi works.

2. With Wayland:
- SAL_USE_VCLPLUGIN=gtk3: Task bar grouping works, scaling in multiple display and different dpi works.
- SAL_USE_VCLPLUGIN=kf6: Task bar grouping works, scaling in multiple display and different dpi does not work.

I get the same results for kf6,kf5,qt6 and qt5. I also tried gtk4 which provides same results as gtk3, but it has problems scaling the mouse (like all gtk4 applications in kde for now).

It should also be noted that all the qt backends (kf5/qt5/kf6/qt6) do not scale properly some icons and texts, while the gtk3 does not seem to have problem like this. However the gtk3 backend is sometimes buggy with the menu bar, which can make the whole window freeze sometimes... But all these problems should better be addressed on another thread in the libreoffice side I guess.

So for now the best configuration I found is wayland with gtk3 backend.

Regarding the taskbar grouping bug, I only get it when forcing the use of xwayland. What is strange is that:
- with the gtk3 backend, I only find the bug with `WAYLAND_DISPLAY= ` but not with `QT_QPA_PLATFORM=xcb`,
- with the kf6 backend, I get the bug in both ways.

I did not try for the moment to setup the environment directly in the desktop files.

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.