[3.3.0] SafeEyes has troubling finding its own icons? #815

Activity

1. archisman-panigrahi commented on Dec 21, 2025

   

   archisman-panigrahi

   on Dec 21, 2025

   Collaborator

   More actions

   Is this a pip install? Do the icon files like /home/user123/.local/share/icons/hicolor/128x128/apps/io.github.slgobinath.SafeEyes.png even exist?
2. hartwork commented on Dec 21, 2025

   

   hartwork

   on Dec 21, 2025

   ContributorAuthor

   More actions

   Is this a pip install?

   It's my Gentoo packaging from gentoo/gentoo@62c61dc that everyone on Gentoo is using.

   Do the icon files like /home/user123/.local/share/icons/hicolor/128x128/apps/io.github.slgobinath.SafeEyes.png even exist?

   No, they don't. I had a pip install --user installation at some point in the past, I think, but cannot find any traces left of it, so I think it's was all gone by the time I witnessed the issue.
3. archisman-panigrahi commented on Dec 21, 2025

   

   archisman-panigrahi

   on Dec 21, 2025

   Last edited by archisman-panigrahi

   Collaborator

   More actions

   (safeeyes:5231): Gtk-WARNING **: 14:42:58.326: Failed to load icon /home/user123/.local/share/icons/hicolor/64x64/apps/io.github.slgobinath.SafeEyes.png: Error opening file /home/user123/.local/share/icons/hicolor/64x64/apps/io.github.slgobinath.SafeEyes.png: No such file or directory
   

   It seems like it is looking for the icon in the home folder while it is supposed to look at the icon in /usr/share/icons/. Could you install v3.2.0 and check if the issue is present there?

   I cannot replicate the issue in either Ubuntu or Arch with v3.3.0, which makes me think that somehow in your system the user packages and system packages got mixed. Could you please double check? Perhaps, start with where safeeyes is installed (is it somehow accidentally installed in your home folder?).

   ---

   Thanks again, for taking care of the Gentoo packaginng

   👍React with 👍1Reacted by Sebastian Pipping
4. hartwork commented on Dec 22, 2025

   

   hartwork

   on Dec 22, 2025

   Last edited by hartwork

   ContributorAuthor

   More actions

   I think I got the answer now:

   • Function safeeyes.utility.initialize_platform creates symlinks to icon images when run from a non-/usr location but not when run from /usr
   • Running SafeEyes from a virtualenv (or non-/usr location) and then deleting that installation leaves broken icon symlinks in place
   • Then running a system-wide SafeEyes does not fix or delete the symlinks but ends up using the links when loading icons

   So the simple reproducer is:

   1. Install SafeEyes system-wide
   2. Create broken icon symlinks à la:

   for i in 16 24 32 48 64 128 ; do mkdir -p ~/.local/share/icons/hicolor/${i}x${i}/apps/ ; done
   for i in 16 24 32 48 64 128 ; do ln -f -s /dev/null ~/.local/share/icons/hicolor/${i}x${i}/apps/io.github.slgobinath.SafeEyes.png ; done

   3. Start SafeEyes
   4. Witness icon issues 😃

   Can you confirm? What do you think of #819?

   Let me boot yet another box…
5. hartwork commented on Dec 22, 2025

   

   hartwork

   on Dec 22, 2025

   ContributorAuthor

   More actions

   Something in the picture is still missing 🤔
6. archisman-panigrahi commented on Dec 22, 2025

   

   archisman-panigrahi

   on Dec 22, 2025

   Collaborator

   More actions

   1. Install SafeEyes system-wide

      2. Create broken icon symlinks à la:

   for i in 16 24 32 48 64 128 ; do mkdir -p ~/.local/share/icons/hicolor/${i}x${i}/apps/ ; done
   for i in 16 24 32 48 64 128 ; do ln -f -s /dev/null ~/.local/share/icons/hicolor/${i}x${i}/apps/io.github.slgobinath.SafeEyes.png ; done

   3. Start SafeEyes
   
   4. Witness icon issues 😃
   

   I could not reproduce on Ubuntu. In terminal, safeeyes does not produce any error messages.
7. archisman-panigrahi commented on Dec 22, 2025

   

   archisman-panigrahi

   on Dec 22, 2025

   Collaborator

   More actions

   Did you test that #819 fixes #815?
   It would still be good to have an exactly reproducible scenario (preferably outside gentoo) so that I can also test. The one you suggested in #815 (comment) does not create any error for me
8. hartwork commented on Dec 22, 2025

   

   hartwork

   on Dec 22, 2025

   ContributorAuthor

   More actions

   @archisman-panigrahi I thought I had it but there is one or more icon cache at play here that I have not gotten control over yet 😞 The fact that DBus handles the tray icon for SafeEyes does not make debugging easy.
9. hartwork commented on Dec 22, 2025

   

   hartwork

   on Dec 22, 2025

   Last edited by hartwork

   ContributorAuthor

   More actions

   @archisman-panigrahi I think I have the missing piece now: xfce4-panel (or the app painting the systray for you) needs a restart to respect filesystem level changes to the SafeEyes icons: it does not react to changes in GTK icon lookup immediately otherwise. This is my current toolbox:

   Debug SafeEyes icon lookup through the eyes of GTK

   debug_safeeyes_icon_location.py

   Shadow all SafeEyes system icons

   for i in 16 24 32 48 64 128 ; do mkdir -p ~/.local/share/icons/hicolor/${i}x${i}/apps/ ; done
   for i in 16 24 32 48 64 128 ; do mkdir -p ~/.local/share/icons/hicolor/${i}x${i}/status/ ; done
   for i in 16 24 32 48 64 128 ; do ln -f -s /dev/null ~/.local/share/icons/hicolor/${i}x${i}/apps/io.github.slgobinath.SafeEyes.png ; done
   for i in 16 24 32 48 64 128 ; do ln -f -s /dev/null ~/.local/share/icons/hicolor/${i}x${i}/status/io.github.slgobinath.SafeEyes-enabled.png ; done
   for i in 16 24 32 48 64 128 ; do ln -f -s /dev/null ~/.local/share/icons/hicolor/${i}x${i}/status/io.github.slgobinath.SafeEyes-disabled.png ; done
   for i in 16 24 32 48 64 128 ; do ln -f -s /dev/null ~/.local/share/icons/hicolor/${i}x${i}/status/io.github.slgobinath.SafeEyes-timer.png ; done

   Remove shadow symlinks

   rm -v ~/.local/share/icons/hicolor/*/*/io.github.slgobinath.SafeEyes*.png

   Restart XFCE 4 panel

   pkill xfce4-panel ; xfce4-panel & disown $!
10. archisman-panigrahi commented on Dec 23, 2025

    

    archisman-panigrahi

    on Dec 23, 2025

    Collaborator

    More actions

    I am still confused about something: If you put empty icon files in .local/share/icons, the system would show the empty icons because stuff in .local/share get higher preference over /usr/share. What is the bug here?
11. hartwork commented on Dec 23, 2025

    

    hartwork

    on Dec 23, 2025

    ContributorAuthor

    More actions

    @archisman-panigrahi with that ⬆️ I can now reproduce (or enforce the issue) on Debian. Can you confirm?
12. hartwork commented on Dec 23, 2025

    

    hartwork

    on Dec 23, 2025

    ContributorAuthor

    More actions

    What is the bug here?

    @archisman-panigrahi the bug arguably is that in particular people debugging or developing SafeEyes can easily get into a situation with broken icons because of the auto-symlink-install mechanism that SafeEyes comes with.
13. hartwork commented on Dec 23, 2025

    

    hartwork

    on Dec 23, 2025

    ContributorAuthor

    More actions

    Which means that PR #819 does indeed solve the problem.
14. archisman-panigrahi commented on Dec 23, 2025

    

    archisman-panigrahi

    on Dec 23, 2025

    Collaborator

    More actions

    In my computer (Linux Mint XFCE), restarting the panel doesn't even show the tray icon anymore (not even an empty space), which is probably #809 . Let me see what happens after restarting

    👍React with 👍1Reacted by Sebastian Pipping
15. hartwork commented on Dec 23, 2025

    

    hartwork

    on Dec 23, 2025

    ContributorAuthor

    More actions

    @archisman-panigrahi I have the same with XFCE, it needs a restart to SafeEyes for a new icon to show up to the tray, true. Sorry for not having been more precise in that regard. it takes a restart to the tray and to SafeEyes.
16. archisman-panigrahi commented on Dec 23, 2025

    

    archisman-panigrahi

    on Dec 23, 2025

    Collaborator

    More actions

    I can replicate the issue now.

    🎉React with 🎉1Reacted by Sebastian Pipping
17. archisman-panigrahi

    added a commit that references this issue on Dec 23, 2025

    Merge pull request #819 from hartwork/issue-815-delete-stale-symlinks

    ...

    This issue will close once commit ab5525d is merged into the 'master' branch.

    ab5525d
18. archisman-panigrahi

    closed this as completedin #819on Dec 23, 2025