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

help gnome users find a way to get statusicon back #2197

Closed
totaam opened this issue Mar 7, 2019 · 3 comments
Closed

help gnome users find a way to get statusicon back #2197

totaam opened this issue Mar 7, 2019 · 3 comments
Labels

Comments

@totaam
Copy link
Collaborator

totaam commented Mar 7, 2019

Follow up for #406.

If we find that the topicons / appindicator extension is not installed, show a warning dialog and offer to install the package (by calling packagekit? only if we know the package name?)
Have an option to not show the dialog again (and save to .local/share/xpra/conf.d/80_gnomeshell_warning.conf?).

If the extension is installed but not enabled, offer to enable it:

Once all of this has been done, offer to restart gnome shell

@totaam
Copy link
Collaborator Author

totaam commented Mar 8, 2019

See also: AppIndicator3 Indicator props connected: True if we have a reasonable expectation of being displayed through this object. You should hide your TrayIcon if so.

@totaam
Copy link
Collaborator Author

totaam commented Jul 24, 2019

Too hard to make this work reliably on all platforms (even just RPM platforms), so WONTFIX.

A "better" solution would be #476, see #2161#comment:3

@totaam totaam closed this as completed Jul 24, 2019
@totaam totaam added the v2.4.x label Jan 22, 2021
totaam added a commit that referenced this issue Sep 9, 2023
use a post-install script to enable the extension for active users
@totaam
Copy link
Collaborator Author

totaam commented Sep 9, 2023

The commit above adds an xpra-client-gnome package.
The post install script will try to enable the appindicator extension for active users.

Enabling system wide is apparently possible but due to the configuration file format, there's a risk we might actually remove existing settings by configuring the enabled-extensions option.
Parsing a potential existing value and appending to it would be preferable, but that's not easy in a shell script.

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

No branches or pull requests

1 participant