To expand a little bit on this. So indeed, what's happening is:
- the client side set some icons/assets in its /tmp (which is != from the system /tmp)
- the client then sends his menu + the icon uri to the system shell
- the system shell tries to open the icon at that address which doesn't exist.
There are multiple issues there:
- as we want snapd to be cross distros, I don't think we can patch Qt, GTK and other toolkits to export indicators with translated path (client side)
- if we go that road, it means we need to make the application aware it's running in a snapd environment, unsure this is wanted
- patching all shells (at least Unity, GNOME Shell and KDE plasma) has the same issue in term of cross distro compatibility (shell-system-side)
- ofc, we don't want /tmp to be the same than the system one
- I don't think apparmor can do this on the fly translations, right? Patching dbus is an option (with a running on snapd awareness), but brings the same issue in term of cross distro distributions.
To expand a little bit on this. So indeed, what's happening is:
- the client side set some icons/assets in its /tmp (which is != from the system /tmp)
- the client then sends his menu + the icon uri to the system shell
- the system shell tries to open the icon at that address which doesn't exist.
There are multiple issues there:
- as we want snapd to be cross distros, I don't think we can patch Qt, GTK and other toolkits to export indicators with translated path (client side)
- if we go that road, it means we need to make the application aware it's running in a snapd environment, unsure this is wanted
- patching all shells (at least Unity, GNOME Shell and KDE plasma) has the same issue in term of cross distro compatibility (shell-system-side)
- ofc, we don't want /tmp to be the same than the system one
- I don't think apparmor can do this on the fly translations, right? Patching dbus is an option (with a running on snapd awareness), but brings the same issue in term of cross distro distributions.
Any other idea?