You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First let me say that I don't know if this is feasible because I lack enough knowledge of D-Bus to be able to say so.
StatusNotifierItem registered by applications uses the PID followed by a number (usually handle incrementally by the app) to define the name of the StatusNotifierItem to register, per the spec.
Unfortunately it doesn't map well with Flatpak applications since they are PID-namespaced and their PID is often a single low digit, so the names will likely clash quite often on system using a lot of Flatpak applications with tray.
Adding to that the need of owning the whole org.kde.* namespace to be able to do so, it seems like a rather bad situation.
Would it be possible to rename StatusNotifierItem objects on the fly when they are created, keep a mapping and forward the requests/responses on this object accordingly ? We could just use the PID of the dbus-proxy itself for example, or something like that.
Or any other idea to improve this situation ?
Thanks.
The text was updated successfully, but these errors were encountered:
First let me say that I don't know if this is feasible because I lack enough knowledge of D-Bus to be able to say so.
StatusNotifierItem registered by applications uses the PID followed by a number (usually handle incrementally by the app) to define the name of the StatusNotifierItem to register, per the spec.
Unfortunately it doesn't map well with Flatpak applications since they are PID-namespaced and their PID is often a single low digit, so the names will likely clash quite often on system using a lot of Flatpak applications with tray.
Adding to that the need of owning the whole
org.kde.*
namespace to be able to do so, it seems like a rather bad situation.Would it be possible to rename StatusNotifierItem objects on the fly when they are created, keep a mapping and forward the requests/responses on this object accordingly ? We could just use the PID of the dbus-proxy itself for example, or something like that.
Or any other idea to improve this situation ?
Thanks.
The text was updated successfully, but these errors were encountered: