Skip to content
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

Handle renaming of StatusNotifierItem object when needed (?) #15

Closed
MatMaul opened this issue May 8, 2020 · 3 comments
Closed

Handle renaming of StatusNotifierItem object when needed (?) #15

MatMaul opened this issue May 8, 2020 · 3 comments

Comments

@MatMaul
Copy link

MatMaul commented May 8, 2020

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.

@matthiasclasen
Copy link
Contributor

it seems like a rather bad situation.

The bad situation really needs to be fixed at the source.

@Erick555
Copy link

Erick555 commented Jun 8, 2023

it was fixed by Qt. The fix is part of KDE runtime. Apps should do this and this issue can be closed.

Electron apps may be still affected but it's their problem

@bilelmoussaoui
Copy link
Member

Let us close this one as it was fixed in Qt already

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants