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

Use dbus to query for org.kde.StatusNotifierWatcher #14635

Closed
ckerr opened this issue Sep 15, 2018 · 1 comment · Fixed by #36333
Closed

Use dbus to query for org.kde.StatusNotifierWatcher #14635

ckerr opened this issue Sep 15, 2018 · 1 comment · Fixed by #36333

Comments

@ckerr
Copy link
Member

ckerr commented Sep 15, 2018

Inspired by #12743

Right now Electron is hardcoding the desktop environments that are known to support app indicators. It would be less hacky to just check and see if StatusNotifierWatcher is owned on the bus.

@ckerr
Copy link
Member Author

ckerr commented Sep 21, 2018

Some notes on this:

  • The bus monitoring would likely be better done in our C++ code. Chromium has a dbus API that could be used for this.
  • For the first deliverable I think it would be enough to say "hasAppIndicator is true iff org.kde.StatusNotifierWatcher is owned by someone on the Session bus."
  • Chromium's Bus::GetServiceOwner() is probably the right API call for this
  • Note a possible point of confusion when you try this with the Chromium dbus API: Their owned_service_names_ is a list of names we own, which is not a good match for this test of "is it owned by anyone", ie "is there a service on the session bus that owns o.k.SNW?"
  • We should research the original motivation behind setting process.env.XDG_CURRENT_DESKTOP = 'Unity' since Unity has been canceled and it's no longer Ubuntu's default desktop environment. Is there some legacy code out there still hardwired to sniff for the name 'Unity' or can we change/remove this?

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

Successfully merging a pull request may close this issue.

2 participants