-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove permissions to unbreak the tray icon #51
Conversation
Started test build 90988 |
Build 90988 successful
|
With this test build I am still not getting the system tray icon. The main difference is that I am not even getting the empty space. So the situation is actually worsened. Seen on Manjaro/Flatpak/KDE. |
I'm not sure why that's happening for you, but I'll say that I tested this on Arch Linux, with three different DEs, and the results are consistent. The KDEkde.mp4GNOMEgnome.mp4XFCExfce.mp4 |
When I start the application with flatpak run, I get the following:
Apparently, I am getting a path to the icon, not the icon data. |
Using |
If you're saying that based only on the output of the program, that's definitely not it. If you watch any of the videos I posted, I also get a similar output. The "conversion" is done by the current Can you verify that you don't have any permission overrides that might be interfering with this? You can check with:
And also global overrides:
Also, can you verify that the KDE portal service is running correctly?
|
Trying to show overrides gives nothing. Checking the portal service give: systemctl --user status plasma-xdg-desktop-portal-kde.service Jan 04 10:33:53 zorrykid xdg-desktop-portal-kde[3082]: xdp-kde-settings: Namespace "org.gnome.desktop.interface" is not supported |
Damn, everything seems in order... :/ One last thing I can think of, and this is a long shot, but maybe the icon is being automatically hidden here: Or manually hidden here: If it's neither of those, then I'd perhaps try to debug this by leaving |
Not hidden. In fact, not appearing at all in "Entries". |
Tried |
Wanted to test on another machine but now getting a 404 from https://dl.flathub.org/build-repo/73671/com.github.KRTirtho.Spotube.flatpakref |
Nope. You should only need one implementation.
I'm at a loss then, lol
I'll trigger a rebuild. bot, build |
Queued test build for com.github.KRTirtho.Spotube. |
Started test build 91492 |
Build 91492 successful
|
Same on the other host (that is also KDE/Wayland/Manjaro, though). |
Can you test it on a X11 session just out of curiosity? I didn't test on Wayland since I have a really old NVIDIA GPU. |
Queued test build for com.github.KRTirtho.Spotube. |
Started test build 91760 |
Build 91760 successful
|
This permission allows us to communicate directly with the org.kde.StatusNotifierWatcher interface, but this is actually a bad idea. Previously, when the app was about to set the tray icon, the org.kde.StatusNotifierWatcher interface would receive the following information: $ dbus-monitor ... array [ dict entry( string "Id" variant string "cac90a20-a943-11ee-86a7-d9e05156d7eb" ) dict entry( string "Category" variant string "ApplicationStatus" ) dict entry( string "Status" variant string "Active" ) dict entry( string "IconName" variant string "/app/spotube/data/flutter_assets/assets/spotube-logo.png" ) ... The problem here is that the path for the icon file in the "IconName" property does not exist outside of the Flatpak sandbox, and therefore the icon file cannot be found or set. By removing this permission, however, the current xdg-desktop-portal implementation should take care of this problem for us automagically. At least on KDE, instead of forwarding the literal path of the icon, only the pixmap data of the icon is sent, through the "IconPixmap" option: $ dbus-monitor ... array [ dict entry( string "Category" variant string "ApplicationStatus" ) dict entry( string "IconPixmap" variant array [ struct { int32 16 int32 16 array of bytes [ ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 [ ... output shortened for readability ... ] ] } ] ) ... Unfortunately, for reasons unbeknownst to me, simply removing the org.kde.StatusNotifierWatcher permission is still not enough to make the tray icon appear on Wayland sessions. However, removing the Wayland permission to make the app run through XWayland, did the trick.
5605510
to
de18037
Compare
Started test build 92931 |
Build 92931 successful
|
I have set up a QEMU virtual machine to test this change on Wayland, and in fact the tray icon didn't show up at all on any of the Wayland sessions. I'm not sure why that is, but for now, the best solution I found is to disable Wayland support in the app, so that it runs through XWayland instead... |
Maybe an approach like bbhtt/net.sourceforge.liferea@ec88547 would be better for fixing this. |
Sure, but there's currently no Flutter SDK on Flathub, and so the application can't be easily patched to be built from source. Not only that, but the tray icon is set up by this third-party library (and arguably incorrectly as well), so we'd have to directly patch the library. For now, I believe the solution I found is better than having an invisible tray icon. |
Another option could be to contribute it upstream as a workaround and put it behind an environment variable for detection (i.e |
on gnome, removing org.kde.StatusNotifierWatcher with flatseal results in no tray icon at all |
Did you remove the Wayland permission as well? |
NOTE: This is not the proper fix by any means; It's only a workaround.
This PR removes both
--talk-name=org.kde.StatusNotifierWatcher
and--socket=wayland
permissions to unbreak the tray icon functionality.The root cause likely needs to be addressed in this third-party library that Spotube uses to set up the tray icon.
Also see antler119/system_tray#67 (comment) for more details.
Using
dbus-monitor
, we can figure out how Spotube is setting the tray icon:The problem here is that the path for the icon file in the
IconName
property does not exist outside of the Flatpak sandbox, and therefore the icon file cannot be found or set.By removing the
--talk-name=org.kde.StatusNotifierWatcher
permission, however, xdg-desktop-portal takes care of this problem for us automagically.At least on KDE, instead of forwarding the literal path of the icon, only the pixmap data of the icon is sent, through the
IconPixmap
option:Although this fixes things on X11 sessions, that's still not enough for Wayland, so that's why it's needed to also remove the Wayland permission so that XWayland is used instead.
Fixes KRTirtho/spotube#541