| Summary: | Fall back to Breeze if icon is not found in the specified icon theme or even in its fallback icon theme | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kiconthemes | Reporter: | David <david.cortes.rivera> |
| Component: | general | Assignee: | Christoph Feck <cfeck> |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | ad.liu.jin, groszdanielpub, kdelibs-bugs, nate |
| Priority: | NOR | ||
| Version: | 5.92.0 | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
David
2022-03-13 17:41:44 UTC
In fact there is no such thing as a "GTK icon theme"; the icon theme you set in the Icons page affects both Qt and GTK apps. It's universal. In the past we let you override the icon theme for just GTK apps, taking advantage of a hidden quick in GTK itself, but we don't support that anymore, sorry. We found that it was much simpler, more comprehensible, and resulted in fewer bugs when we used one icon theme for everything. (In reply to Nate Graham from comment #1) > In fact there is no such thing as a "GTK icon theme"; the icon theme you set > in the Icons page affects both Qt and GTK apps. It's universal. > > In the past we let you override the icon theme for just GTK apps, taking > advantage of a hidden quick in GTK itself, but we don't support that > anymore, sorry. We found that it was much simpler, more comprehensible, and > resulted in fewer bugs when we used one icon theme for everything. This feature removal results in some places where an icon should be ending up with no icon when a non-default icon theme is selected. That would be a bug in the icon theme itself, or in the app. Depends in the details of the situation. When you run into such an example, you should file a bug report on the icon theme itself so the developers can fix it and users don't have to work around it. :) Can you mention some examples? (In reply to Nate Graham from comment #3) > That would be a bug in the icon theme itself, or in the app. Depends in the > details of the situation. When you run into such an example, you should file > a bug report on the icon theme itself so the developers can fix it and users > don't have to work around it. :) > > Can you mention some examples? I doubt it is a bug in the icon theme. Most icon themes out there do not have icons for everything that breeze sets icons for - there used to be an option of fallback theme for those cases, but it's not there anymore. As an example, set the "papirus dark" icon theme, and then launch synaptic under the latest KDE. Then try the older KDE that allowed different GTK icons, set "oxygen" as the GTK icon theme with "adwaita dark" as fallback, launch synaptic again, and compare. Icon themes themselves specify what their fallback theme is. Being able to override that but just for GTK apps was weird and confusing because the setting then't take effect for Qt apps as well. That was one of the reasons why we removed it. Ultimately it's up to icon themes to set a sane fallback. However I do see something we could do to improve the situation, given the world we live in where there are 527603 crappy incomplete icon themes that don't set their fallback to something sane (typically Breeze or Adwaita, which can both be considered to be more or less complete). We could make Breeze always be the ultimate fallback in cases where the requested icon isn't even found in the icon theme's fallback theme. *** This bug has been marked as a duplicate of bug 484639 *** Reopening this as (as far as I understand) it hasn't been fixed, but it has been marked as a duplicate of (Bug 484639, which has ambiguously been used to track another bug as well as this one) has been closed as fixed. I'm also changing it from wishlist to normal, since from comments on Bug 484639 it appears the requested behavior is actually the intended one. As I understand, there are 3 ways to fix missing icons when using Oxygen: (1) Have icons for them in Oxygen style: draw new icons when necessary, or copy them from the Plasma 5 Air theme when they already existed there. (This has been reported as Bug 483496) (2) Fall back to Breeze if an icon isn't found in either the user's icon theme, nor any fallback theme. (I figured this bug, Bug 451463, was used primarily to track this. As I understand from comments on Bug 484639, it's actually supposed to behave that way, actually a bug that it ) (3) Specify Breeze as a fallback theme of Oxygen. (I opened Bug 484639 to track this particular solution, but a developer changed its title to refer to (2), and closed all bugs about missing icons, including this one, as a duplicate of that one.) In Comment 5 of this bug, Nate suggested that both (3) and (2) are desirable to implement, with it being primarily any unofficial theme's responsibility to set a reasonably complete icon theme as their fallback, i.e. (3) being the more important to implement. In comments on Bug 484639, however, people have said that (2) is the proper way to fix this, and that (3) may even be undesirable; (2) is also more reliable in that it works even with old icon themes that have become unmaintained before the current default theme even existed. Now Nuno Pinheiro has fixed (1) and (3). He draw the missing icons for Oxygen shortly after Plasma 6 came out, but hadn't made a release until recently, so they weren't picked up by most distros. Now he released them in Oxygen icons 6.1.0, which also sets breeze as a fallback, and closed Bug 484639. Relevant comments from Bug 484639: Jin Liu https://bugs.kde.org/show_bug.cgi?id=484639#c1 > I think, as Nate said, Plasma should implicitly fallbacks to Breeze when the > icon theme "inherits=" setting doesn't find an icon. Jin Liu https://bugs.kde.org/show_bug.cgi?id=484639#c2 > This is caused by > https://invent.kde.org/frameworks/kiconthemes/-/blob/master/src/kicontheme.cpp?ref_type=heads#L96 > initialized after: > https://invent.kde.org/frameworks/kiconthemes/-/blob/master/src/kiconloader.cpp?ref_type=heads#L1471 > So the icon loader doesn't use Breeze as the ultimate fallback. > > Oxygen (and other themes) doesn't need to explicitly fallback to Breeze, if > the above bug is fixed. Jin Liu https://bugs.kde.org/show_bug.cgi?id=484639#c6 > Also note that `setBreezeFallback` doesn't handle Breeze-twilight correctly. Loïc Yhuel https://bugs.kde.org/show_bug.cgi?id=484639#c9 > (In reply to Jin Liu from comment #1) > > I think, as Nate said, Plasma should implicitly fallbacks to Breeze when the > > icon theme "inherits=" setting doesn't find an icon. > Ideally, it should depend on whether the plasma style is dark or not, since > the breeze icons are almost invisible on black backgrounds. > So with Oxygen and Breeze Dark, it should fallback to breeze-dark. Jin Liu https://bugs.kde.org/show_bug.cgi?id=484639#c10 > (In reply to Grósz Dániel from comment #7) > > Well, I interpreted Nate as saying that, while it might make sense to use > > Breeze a fallback even if it's not explicitly specified as an inherited > > theme, it's also desirable for every theme to explicitly specify a > > presumably complete theme (Breeze, Adwaita) as an inherited theme. > > It might not be desirable, as you probably want a 3rd-party icon theme > to fallback to Breeze in KDE, and Adwaita in GNOME. I don't see how that > would work with "inherits=". |