Qt apps, like kid3-qt, which uses legacy icons "document-*.png", show them as normal document icon under Yaru theme

Bug #1853768 reported by Amr Ibrahim
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Yaru Theme
Fix Released
Unknown
yaru-theme (Ubuntu)
Fix Released
Undecided
Unassigned
Eoan
Won't Fix
Undecided
Unassigned

Bug Description

Qt apps, like kid3-qt, which uses these legacy icons:

document-open.png
document-open-recent.png
document-save.png
document-save-as.png
document-revert.png
document-import.png
document-export.png

The icons are all shown as the same normal document icon under Yaru.

Qt apps only have a problem with legacy icons starting with "document-*" and all other legacy icons are inherited from Humanity under Yaru.

Is there a general solution to force Qt apps to choose the closest icon name from Yaru or Humanity?

Should this bug be issued against upstream Qt?

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in qtbase-opensource-src (Ubuntu):
status: New → Confirmed
Changed in yaru-theme (Ubuntu):
status: New → Confirmed
Changed in yaru:
status: Unknown → New
Changed in yaru:
status: New → Fix Released
Revision history for this message
Dmitry Shachnev (mitya57) wrote :

When an icon is missing (e.g. document-open), Qt first falls back to splitting the name by dashes and taking the first part of it (document). Only then it falls back to parent icon themes (Yaru → Humanity). So for all document-* icons it uses document.png from MimeTypes context.

Doing it vice versa would fix the bug. However, the specification explicitly tells us to behave as Qt currently does: https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#guidelines

> if the more specific item does not exist in the current theme, and does exist in a parent theme, the generic icon from the current theme is preferred, in order to keep consistent style.

Another potential fix would be ignoring the MimeTypes context. The specification says that fallback happens “for all contexts other than MimeTypes”. However currently Qt’s icon loader does not take contexts into account at all. So fixing it in Qt would be difficult.

I have just pinged the Yaru theme maintainer, let’s hope the fix from Yaru will land in Ubuntu soon.

Revision history for this message
Amr Ibrahim (amribrahim1987) wrote :

Just a bit of context:
Symbolic action icons are the de-facto in a GNOME environment, full-colour icons are legacy, that's why Yaru theme didn't originally have any "legacy" full-colour action icons as its original author refused to do so.
The recent addition of the coloured document-*.png icons in Yaru is just a workaround for Qt apps in order not to appear broken under Yaru. And not all full-colour icons will be in Yaru, only the needed document-*.png ones.

Revision history for this message
Dmitry Shachnev (mitya57) wrote :

In Focal this is now fixed in yaru-theme 20.04.1.

no longer affects: qtbase-opensource-src (Ubuntu)
Changed in yaru-theme (Ubuntu):
status: Confirmed → Fix Released
Changed in yaru-theme (Ubuntu Eoan):
assignee: nobody → Dmitry Shachnev (mitya57)
Revision history for this message
Dmitry Shachnev (mitya57) wrote :

Sorry, I had no time and didn't upload a fix for Eoan. Now that Ubuntu 20.04 released, I am no longer interested in Eoan fix.

Changed in yaru-theme (Ubuntu Eoan):
assignee: Dmitry Shachnev (mitya57) → nobody
Changed in yaru-theme (Ubuntu Eoan):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.