Theme breaks default icons about morewaita HOT 32 CLOSED

I've tried changing the Inherits property to default but it didn't fix it. I'd recommend now updating that property to either just Adwaita (since Adwaita in turn inherits hicolor) or default which would be more generic. If the theme inherits Adwaita, distribution packages should probably add the adwaita-icon-theme as a dependency. If not it inherits the default theme, then theme dependencies are not needed.

This is mostly fine tuning the theme but it would be nice to clear that up.

from morewaita.

There is an algorithm how icons are looked up documented on the FreeDesktop Icon Theme spec website. This might help out with the debugging.

I've also sent a message in GNOME channel on matrix to see if there is a way to get some kind of a log what icon themes are tried for those missing resources. Once I get a response I'll post more information here.

from morewaita.

I found a tool that might be of help in finding where your system is looking for icons: bastimeyer/freedesktop-icons.

I've just tried it and doesn't seem to work, event with MoreWaita disabled. I'm not sure why but I don't really have time to debug it.

Developers in GNOME matrix channel have pointed me to gtk/gtkicontheme.c in order to see how icons are loaded. I'll try if I get some free time to understand the code and see what's going on there.

from morewaita.

Hi. I had a similar problem with some Flatpak apps not displaying all icons properly inside the app, instead having a "missing picture" icon like in the picture from @dusansimic .

I was able to solve it be giving all flatpak access to the home/.icons directory where I had installed the Moredwaita icon pack, with flatpak override --filesystem=$HOME/.icons

I don't know if that helps

from morewaita.

Thanks for reporting this.
This is weird. The theme is explicitly set to fall back to Adwaita and then hicolor, so any missing icons in MoreWaita should automatically be picked up from Adwaita, and if not there, then hicolor. I'll look into this, but any suggestions or info you come across are welcome.

from morewaita.

I'd recommend now updating that property

Changed to just Adwaita in git. Will be looking more into this tomorrow.

from morewaita.

This might help out with the debugging.

Unfortunately, it's just a specification. I've been through it many times before and again now. It does define general rules, but they're more like recommendations since the document references 'implementations', which means each distro and/or DE can diverge from this specification in how they implement icons.

I found a tool that might be of help in finding where your system is looking for icons: https://github.com/bastimeyer/freedesktop-icons.

Sorry, didn't have time to check the branch of your app. Tried the regular one from AUR, but that doesn't seem to have any broken icons.

from morewaita.

I might have some time today or tomorrow to have a look at both your new branch and the tool. Hopefully we'll figure it out.

from morewaita.

@dusansimic Just had a meeting cancelled so I tried the branch of Dynamic Wallpaper you mentioned, and all icons seem to work fine for me (Arch, Gnome Shell 42.5). Here's what I'm getting:

That's with MoreWaita enabled.

By the way, how do I uninstall the app?

from morewaita.

For me it happens on Arch (GNOME 43, from fcgu) and Fedora Silverblue 37 (GNOME 43).

There are different ways to uninstall it depending on which method you used to install it. If you installed it as a flatpak or any other package manager, just remove the package. If you installed it with meson install, you should be able to just run meson uninstall and it will remove the app.

from morewaita.

Could be Gnome 43 related then. It's already in Testing, so I'll wait for it to hit the stable repos and test/debug then.

I installed the branch following your instructions in the readme: cloned it and then did meson _build --prefix=/usr && cd _build and sudo ninja install. I'll keep it for testing until Gnome 43 arrives.

from morewaita.

So I updated to Gnome 43. Still see the icons with both MoreWaita and Adwaita the same.
I saw people on Reddit mentioning other glitches with icon themes and cursor themes not being applied properly after the update. Don't know what else I can do.

from morewaita.

Can confirm I had to re-apply the theme after updating to Gnome 43, all the icons especially the ones in Nautilus were completely broken. A simple re-set to MoreWaita in Gnome Tweaks solved it. Idk if its the same thing though

from morewaita.

For me it happens on Arch GNOME 43

This may sound stupid, but have you tried sudo gtk-update-icon-cache -f -t /usr/share/icons/MoreWaita && sudo gtk4-update-icon-cache -f -t /usr/share/icons/MoreWaita?
(I'm not sure whether there's a difference between those two commands, so I use both for good measure.)

from morewaita.

This may sound stupid, but have you tried sudo gtk-update-icon-cache -f -t /usr/share/icons/MoreWaita && sudo gtk4-update-icon-cache -f -t /usr/share/icons/MoreWaita?

I've just tried it and it doesn't work. On Arch gtk-update-icon-cache is run by a hook on package install/update when that package installs/updates anything in /usr/share/icons. Also gtk-update-icon-cache is just a link to gtk4-update-icon-cache.

from morewaita.

Can you try also doing sudo gtk-update-icon-cache -f -t /usr/share/icons/Adwaita and sudo gtk-update-icon-cache -f -t /usr/share/icons/hicolor?

from morewaita.

I found the same problem in Evolution in Fedora 37(Installed through COPR).
With the Morewaita:

With the standard:

from morewaita.

I've been researching this issue, and have come across two things that seem to shed some light on what's going on.

• First, a merge in GLib 4 years ago changed the way icon inheritance between themes works on Gnome, which may or may not be related to what we have here.
• Second, a similar issue has revealed that some icons go missing if a theme is installed at user level.

@rafatosta @dusansimic do you have MoreWaita installed locally or system-wide? If locally, can you try installing system-wide and seeing if that brings the missing icons back?

from morewaita.

The installation I have and the print is throughout the system through the Fedora COPR

from morewaita.

do you have MoreWaita installed locally or system-wide? If locally, can you try installing system-wide and seeing if that brings the missing icons back?

I have it installed system wide on one machine an locally on the other, both have the same issue.

I'm sorry for the radio silence, I didn't have enough free time to dedicate myself to this issue. I'd just like to mention that the issue is mostly gone now but just for the apps that are installed on the system. For the apps that are in development and that are run through GNOME Builder for example, have some symbolic icons missing. I'm still not sure what's causing this.

from morewaita.

Back online after a hectic end of year. Swapped my SSD among other things, and used the opportunity to reinstall my Arch from scratch using btrfs this time.

So, on a clean Arch install I'm not seeing missing icons except for one extension's (Unite) options, where they reference some icon that doesn't exist on the system at all, no matter which icon theme is used. Other than that, enabling MoreWaita does not make any icons disappear on a clean Arch install for me.

The mystery remains to be solved.

from morewaita.

I had this problem with "GNOME Text Editor" installed from the Fedora flatpak repo. Ones replaced with the Flathub version, the symbolic icons started to work properly.

System:
Fedora Silverblue 37, Gnome 43.2

from morewaita.

Found the same issue on flatpak apps. Solved by moving the MoreWaita to /usr/share/icons instead of ~/.icons

from morewaita.

Sometimes, there are high priority icon caches remaining from uninstalled icon themes that cause these kinds of issues. Run the following commands (preferably as a script) to get a list of all icon themes which have cache files on the system.

XDG_DATA_HOME={$XDG_DATA_HOME:-$HOME/.local/share}
XDG_DATA_DIRS={$XDG_DATA_DIRS:-/usr/local/share/:/usr/share}

OLD_IFS=$IFS
IFS=:

for data_dir in $XDG_DATA_HOME $XDG_DATA_DIRS; do
  for theme_dir in "$data_dir"/icons/*/; do
    if test -e "$theme_dir"/icon-theme.cache; then
      echo "$theme_dir"
    fi
  done
done

IFS=$OLD_IFS

# Special case for ~/.icons directory
for theme_dir in ~/.icons/*/; do
  if test -e "$theme_dir"/icon-theme.cache; then
    echo "$theme_dir"
  fi
done

Once you know which icon themes have cache files, you can remove or update any suspicious cache files. Some criteria for sus caches is

• Cache file exists for a theme that does not exist anymore (you may have removed it)
• Cache files that exist in /usr/local/share instead of /usr/share or in ~/.icons instead of $XDG_DATA_HOME (~/.local/share).

from morewaita.

@somepaulo The issue is probably that the 'Actions' icons are missing. You will have to find a way to include them and add them to index.theme.

from morewaita.

@somepaulo The issue is probably that the 'Actions' icons are missing. You will have to find a way to include them and add them to index.theme.

If that's the case, then it's a bug in the spec implementation in GNOME. Inheritance should work, so any icons not present in this theme should (and do on my system) get picked up from the parent (Adwaita in this case) theme, which, in turn, refers up to the hicolor theme.

from morewaita.

Inheritance should work

I agree, it should, but it doesn't always work. Evolution doesn't show symbolic icons at all for actions and folders. That is because Evolution's icons are in /usr/share/evolution/icons/hicolor. You can work around this by adding action and folder icons to MoreWaita.

from morewaita.

I've opened an issue with Gnome devs, and in their first approach everything worked for them. No issue at all.

I've installed Evolution on my system, and was able to replicate this issue. It's the only affected app for me though. The same icons appear fine in other apps.

I've provided more details and asked for pointers on the issue above. Let's see what gives.

from morewaita.

I've opened an issue with Gnome devs

The issue was closed with the verdict that it was an Evolution problem.
Evolution introduced an option to mitigate this, discussed here.

So I'm considering this solved for now.
Feel free to reopen if anything new comes up.

from morewaita.

So, I'm not sure how exactly this issue got fixed, but I still get the same behavior on arch linux.

from morewaita.

Here's a video that shows the behavior.

from morewaita.

This is an issue with how a particular app calls for icons.
I said it got fixed since it had only been reported in Evolution, and they fixed that upstream. You're, clearly, using some other app that calls for icons differently than Gnome expects.

from morewaita.