Open mcrha opened 3 years ago
For context, what is the practical consequence of this?
I don't know exactly why, but flatpak copies /usr/share/icons/hicolor/index.theme
into the exports directory in gtk-icon-cache.trigger
. Presumably the intent is to make gtk-update-icon-cache
generate a cache. I don't know if --ignore-theme-index
would have the same effect; would GTK use the cache without an index.theme?
The index.theme file defines what directories the theme contains, thus where to look for the icons. When the user-chosen theme does not match the first-found index.theme, then the result is "not found" icon. For example the Adwaita theme moved to a different directory listing.
What precisely gtk4 does I do not know.
This is almost 3 years old bug. I do now know what changed since then. Maybe gtk3 (or even gtk4) covered the problem on its own. That needs to be re-tested. Sadly, I did not provide any reproducer for this in the 2021.
Even I do not like the following... nobody else had a problem with this for those almost 3 years, thus feel free to just close this, as it has no real bad impact for the users. It can be reopened in case the bad impact would be observed later.
Checklist
Flatpak version
1.12.2
What Linux distribution are you using?
Fedora Linux
Linux distribution version
35
What architecture are you using?
x86_64
How to reproduce
Flaptak should not export
index.theme
files, because it confuses gtk3. The gtk3 searches for the theme definition in the search paths (gtk_icon_theme_append_search_path()/gtk_icon_theme_prepend_search_path()) and the first path with theindex.theme
file is considered the theme definition. As I have installed/home/mcrha/.local/share/flatpak/exports/share/icons/hicolor/index.theme
, this file is considered as the theme definition for thehicolor
fallback theme, instead of the system-installed/usr/share/icons/hicolor/index.theme
.Expected Behavior
No
index.theme
file installed on the host system.Actual Behavior
The
index.theme
file is installed and taken by the gtk3 on the host system.Additional Information
No response