| Summary: | When an icon isn't found in the theme, look in its fallback theme before falling back to a more generic icon in the current theme | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kiconthemes | Reporter: | Kristen McWilliam <kmcwilliampublic> |
| Component: | general | Assignee: | Christoph Feck <cfeck> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | carl, josh, kde, kdelibs-bugs, nate, noahadvs |
| Priority: | NOR | Keywords: | usability |
| Version: | 5.111.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=445804 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Shows annotations toolbar with incorrect icons | ||
|
Description
Kristen McWilliam
2023-10-25 14:41:25 UTC
I'm afraid this isn't the way Freedesktop icon themes work. When the requested icon in the current theme is missing, the fallback icon is generated by chopping off the last word of the missing icon and then seeing if the icon theme has an icon by that name. In this case, it does. Whether this behavior is appropriate or not could be debated. I can definitely see the argument that is causes icons to become needlessly generic and maybe even meaningless. However we oughtn't break the spec just because of this; we should change it instead. Agreed, the behaviour seems slightly problematic - as evidenced by every missing icon here falling back to "draw" instead of "draw-highlight", "draw-arrow", etc. Indeed. Ordinarily I might recommend that you bring this up upstream, but TBH I doubt it would get anywhere. The FreeDesktop icon spec is probably one of the most problematic ones out there, with major glaring flaws and unclear paths to compliance by icon themes. It's for this reason that GNOME has started abandoning it. We like to play nice and adhere to common standards in KDE, but sometimes this bites us in cases where the common standards themselves aren't ideal. We could probably change KIconLoader to fall back to an icon in the fallback theme for every single icon that's missing from the active theme, but this would cause the iconography of apps' to switch between two styles much more commonly. And again, it would break the spec. But maybe that's the lesser of two evils? Worth bringing up in a Gitlab Issue at https://invent.kde.org/groups/teams/vdg/-/issues, IMO. Do you have a reference for this behaviour? Accoring to the Freedesktop Icon Theme Spec (https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html): "Inherits: The name of the theme that this theme inherits from. If an icon name is not found in the current theme, it is searched for in the inherited theme (and recursively in all the inherited themes)." I checked Tela, and it does specify Inherits: "Inherits=hicolor,Adwaita,breeze". I haven't seen anything about how it searches for the first part of the name instead so far. Check out the part that starts with "In some cases you don't always want to fall back to an icon in an inherited theme." Thank you~ I read through the spec.. "In some cases you don't always want to fall back to an icon in an inherited theme. For instance, sometimes you look for a set of icons, prefering any of them before using an icon from an inherited theme. To support such operations implementations can contain a function that finds the first of a list of icon names in the inheritance hierarchy . . . This can be very useful for example when handling mimetype icons, where there are more and less "specific" versions of icons." This sounds to me like it is intended to be optional, and only for specific circumstances. I'm not actually clear on why this behaviour would be desired instead of a fallback theme really. Interesting. After reading that again, it does indeed seem like there's wiggle room here for our implementation to have a different behavior. I'm re-opening this ticket and moving it to KIconThemes, where KIconLoader (which implements this behavior) lives, and also CCing people who have thoughts on icon theming from the perspective of an app developer, who can check my reasoning. I think the idea is to preserve visual fidelity by not presenting icons from multiple themes in the same UI. But I agree that it's probably better to do so than to preserve visual fidelity at the costs of losing meaning. Might be mutually exclusive with what's requested in Bug 445804. I like the way you re-worded the title here, checking for the fallback theme _and then_ a generic icon in the current theme sounds quite reasonable (at least at first glance, I am not super familiar with the intricacies.) (In reply to Nate Graham from comment #8) > Might be mutually exclusive with what's requested in Bug 445804. Seems like it, which is troubling since both have a point. This bug (476084): A tool icon must look like the corresponding tool to make sense. Even if it looks worse, the usability is much better. That bug (445804): A templates folder doesn't necessarily have to have a templates folder icon to make sense. A generic folder icon in the same theme would look better than a templates folder icon from a different theme. Agreed, I can see value to both. I am not sure how to reconcile that. |