| Summary: | Using the Breeze icon theme for LibreOffice results in small icons always being used even when large ones should be used--and are available (visible in Task Switcher with Large Icons) | ||
|---|---|---|---|
| Product: | [Plasma] Breeze | Reporter: | Nate Graham <nate> |
| Component: | Icons | Assignee: | visual-bugs-null |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | bugseforuns, kainz.a, nate |
| Priority: | NOR | ||
| Version First Reported In: | 5.10.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| URL: | https://bugs.documentfoundation.org/show_bug.cgi?id=65754 | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=351055 | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Task Switcher showing ugly pixellated icons for LibreOffice programs
`xprop` output |
||
Created attachment 105866 [details]
Task Switcher showing ugly pixellated icons for LibreOffice programs
Created attachment 105867 [details]
`xprop` output
Reproduces with (K)Ubuntu's packages for LibreOffice and Breeze, so this isn't an openSUSE-specific issue. Investigating deeper, this isn't an issue with Breeze. In [libreoffice source dir]/vcl/unx/generic/window/salframe.cxx, Libreoffice is setting NET_WM_ICON (which KWin consumes) to point to a low-res bitmap icon inside a theme zip file provided by the libreoffice-style-[style] packages; e.g. /usr/share/libreoffice/share/config/images_breeze.zip/res/odt_48_8.png This icon looks *awful* in the Large Icons task switcher. It's particularly bad for the Breeze theme icon they provide, but it's not particularly good for any of the others either. Irrespective of what icon theme is chosen internally, LibreOffice should populate NET_WM_ICON with an icon chosen by the system theme, e.g. /usr/share/icons/breeze/apps/48/libreoffice-writer.svg This issue is triggered by KWin's icon handling behavior, as explained in https://bugs.kde.org/show_bug.cgi?id=351055 Basically, rather than displaying the icons specified in their .Desktop files, KWin lets programs choose their own icons for their windows in the Task Switcher, and a lot of programs make really bad choices or provide terrible, low-res icons. Either way, this isn't Breeze's fault. Either LibreOffice needs to make better icon choices, or KWin needs to give up and use the icons specified in the .desktop file. The upstream bug for LibreOffice is https://bugs.documentfoundation.org/show_bug.cgi?id=65754 |
Linux distribution: openSUSE Tumbleweed Desktop environment: KDE Plasma 5.10 LibreOffice version: 5.3.3.2 Steps to reproduce 1. Use the Large Icons Task Switcher style (System Settings > Window Management > Task Switcher > Visualization > Large Icons 2. Install LibreOffice 3. Install the breeze icon theme ('libreoffice-icon-theme-breeze' package in openSUSE) 4. Tell LibreOffice to use the Breeze icon theme (LibreOffice > Tools > Options > LibreOffice/View > Icon Style > Breeze) 5. Restart LibreOffice 6. Hit alt-tab to bring up the Task Switcher Expected results: - The Task Switcher viewer shows nice pretty large icons for all programs Actual results: - All programs except for LibreOffice programs have nice icons; LibreOffice programs have ugly pixellated small icons that come from e.g. /usr/share/libreoffice/share/config/images_breeze.zip/res/odg_16_8.png Reproducibility: - Only happens when using the Breeze icon theme in LibreOffice. If you change the theme to Oxygen (LibreOffice > Tools > Options > LibreOffice/View > Icon Style > Oxygen a correct large icon is shown in the Task Switcher. Additional information: I've attached the output of `xprop` on an affected LibreOffice window. It shows that a small icon is used for the large icon sizes. There are already many perfectly nice large icons available on the system, including one within the Breeze theme icon set itself: /usr/share/libreoffice/share/config/images_breeze.zip/res/*128.png /usr/share/icons/breeze/apps/48/libreoffice-*.svg /usr/share/icons/hicolor/256x256/apps/libreoffice-*.png One of these should be shown instead--probably the first.