github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #236] Systray icon should "Show" GUI #190

New issue

Open

opened 2026-05-05 05:38:02 -06:00 by gitea-mirror · 12 comments

gitea-mirror commented

2026-05-05 05:38:02 -06:00

Owner

Originally created by @brianjmurrell on GitHub (Jan 23, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/236

Operating Systems

Server: Linux

Client: Linux

Barrier Version

2.1.2

Steps to reproduce bug

Start barrier GUI
Connect to (server or client -- problem applies on both)
Close the GUI
Click the GUI icon in the systray using the primary mouse button
Observe that nothing happens
Secondary (right) click the systray icon
Observe the Show option

That secondary-click menu option Show should be the behaviour if you primary click the systray icon.

Originally created by @brianjmurrell on GitHub (Jan 23, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/236 ### Operating Systems ### Server: Linux Client: Linux ### Barrier Version ### 2.1.2 ### Steps to reproduce bug ### 1. Start `barrier` GUI 1. Connect to (server or client -- problem applies on both) 1. Close the GUI 1. Click the GUI icon in the systray using the primary mouse button 1. Observe that nothing happens 1. Secondary (right) click the systray icon 1. Observe the _Show_ option That secondary-click menu option _Show_ should be the behaviour if you primary click the systray icon.

gitea-mirror added the

enhancement

linux

labels 2026-05-05 05:38:02 -06:00

gitea-mirror commented

2026-05-05 05:38:08 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jan 23, 2019):

What DE are you on?

@AdrianKoshka commented on GitHub (Jan 23, 2019): What DE are you on?

gitea-mirror commented

2026-05-05 05:38:11 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 23, 2019):

GNOME 3

@brianjmurrell commented on GitHub (Jan 23, 2019): GNOME 3

gitea-mirror commented

2026-05-05 05:38:15 -06:00

Author

Owner

@TafThorne commented on GitHub (Jan 24, 2019):

If we wait long enough this problem will resolve itself as the system tray is removed.

@brianjmurrell could I ask for your input on something discussed under #155, please?

If the system tray icon where to be removed, what functionality would you miss from it? Would clicking on the main application icon to reload the front end be good enough to cover your needs?

@TafThorne commented on GitHub (Jan 24, 2019): If we wait long enough this problem will resolve itself as the system tray is removed. @brianjmurrell could I ask for your input on something discussed under #155, please? If the system tray icon where to be removed, what functionality would you miss from it? Would clicking on the main application icon to reload the front end be good enough to cover your needs?

gitea-mirror commented

2026-05-05 05:38:17 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 24, 2019):

If the system tray icon where to be removed, what functionality would you miss from it?

A quick/easy way to open the GUI to be able to stop barrier. I understand that I can just run barrier to achieve the same thing but ultimately that's more interactions (overview->[search|favourites|programs]-click) to get the same result.

Is this systray-going-away thing happening in GNOME 3 in general or this Ubuntu effing things up once again? Didn't they learn with Unity?

@brianjmurrell commented on GitHub (Jan 24, 2019): > If the system tray icon where to be removed, what functionality would you miss from it? A quick/easy way to open the GUI to be able to stop barrier. I understand that I can just run barrier to achieve the same thing but ultimately that's more interactions (overview->[search|favourites|programs]-click) to get the same result. Is this systray-going-away thing happening in GNOME 3 in general or this Ubuntu effing things up once again? Didn't they learn with Unity?

gitea-mirror commented

2026-05-05 05:38:20 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jan 24, 2019):

GNOME 3 in general to my knowledge.

@AdrianKoshka commented on GitHub (Jan 24, 2019): GNOME 3 in general to my knowledge.

gitea-mirror commented

2026-05-05 05:38:21 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 24, 2019):

https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/

So, what GNOME seems to be saying is that by default they are not going to show status icons in any way. It seems they started in that direction with that pull-out strip on the bottom left of the desktop. One of the first things I did, which the above blog post even councils was to install TopIcons Plus by phocean.

So, is there any harm in keeping the systray functionality for those that install some kind of systray representation for their DE and letting people who don't install such a thing just not get the systray functionality? That seems to be what GNOME are suggesting.

@brianjmurrell commented on GitHub (Jan 24, 2019): https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/ So, what GNOME seems to be saying is that **by default** they are not going to show status icons in any way. It seems they started in that direction with that pull-out strip on the bottom left of the desktop. One of the first things I did, which the above blog post even councils was to install [TopIcons Plus by phocean](https://extensions.gnome.org/extension/495/topicons/). So, is there any harm in keeping the systray functionality for those that install some kind of systray representation for their DE and letting people who don't install such a thing just not get the systray functionality? That seems to be what GNOME are suggesting.

gitea-mirror commented

2026-05-05 05:38:23 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Jan 24, 2019):

I think that'd be a smart idea.

@AdrianKoshka commented on GitHub (Jan 24, 2019): I think that'd be a smart idea.

gitea-mirror commented

2026-05-05 05:38:25 -06:00

Author

Owner

@TafThorne commented on GitHub (Jan 25, 2019):

The only harm is the delay or polling needed to decide if the system tray is not available or has become available. In the present release, the application waits for up to 20 seconds and repeatedly checks if the system tray has become available. The options I can think of are:

Drop system tray support, speeding up the application start when it is not available (which is the default on new Linux GUI going forward)
If systemtray is not available at application startup, assume that it never will be and skip loading the icon. This will make the application start sooner but it would require an application restart if system tray support became available. AFAIK the system tray support does not load until after the user has logged in + some time.
Check once without a wait when the application is loaded, then poll for system tray support in the background. Ideally, this would be infrequent and limited to a short duration similar to the present startup delay, just without the startup delay. Probably the best overall user experience but the hardest solution to code.

@TafThorne commented on GitHub (Jan 25, 2019): The only harm is the delay or polling needed to decide if the system tray is not available or has become available. In the present release, the application waits for up to 20 seconds and repeatedly checks if the system tray has become available. The options I can think of are: 1. Drop system tray support, speeding up the application start when it is not available (which is the default on new Linux GUI going forward) 1. If systemtray is not available at application startup, assume that it never will be and skip loading the icon. This will make the application start sooner but it would require an application restart if system tray support became available. AFAIK the system tray support does not load until after the user has logged in + some time. 1. Check once without a wait when the application is loaded, then poll for system tray support in the background. Ideally, this would be infrequent and limited to a short duration similar to the present startup delay, just without the startup delay. Probably the best overall user experience but the hardest solution to code.

gitea-mirror commented

2026-05-05 05:38:29 -06:00

Author

Owner

@TafThorne commented on GitHub (Jan 25, 2019):

I would propose taking option 3 and performing the work under #155. Keep this ticket around to address whatever is wrong with the GUI not loading in response to the tray icon interaction.

@TafThorne commented on GitHub (Jan 25, 2019): I would propose taking option 3 and performing the work under #155. Keep this ticket around to address whatever is wrong with the GUI not loading in response to the tray icon interaction.

gitea-mirror commented

2026-05-05 05:38:31 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 25, 2019):

Agree on option 3, on all points.

@brianjmurrell commented on GitHub (Jan 25, 2019): Agree on option 3, on all points.

gitea-mirror commented

2026-05-05 05:38:35 -06:00

Author

Owner

@jjaaccoobb commented on GitHub (May 18, 2020):

It is nice to use the GUI, however very seldom. pkill barrier suffices.

I am still interested in this because even after the system tray unavailable message window appears, Barrier starts successfully and continues to run when the GUI is closed.

The unavailable system tray message is misleading in how it says "do not close the window" because the process is still running after closing the main window.

@jjaaccoobb commented on GitHub (May 18, 2020): It is nice to use the GUI, however very seldom. `pkill barrier` suffices. I am still interested in this because even after the system tray unavailable message window appears, Barrier starts successfully and continues to run when the GUI is closed. The unavailable system tray message is misleading in how it says "do not close the window" because the process is still running after closing the main window.

gitea-mirror commented

2026-05-05 05:38:39 -06:00

Author

Owner

@BenjaminJacober commented on GitHub (Apr 7, 2021):

Ive got the same problem. Using Linux Pop!_OS 20.10. The https://extensions.gnome.org/extension/615/appindicator-support/ extension is on by default and works well with other applications like Steam or Teams.
Running gammy by clicking its icon nothing happens, running it with "gammy" in a terminal results in the same.
Only when running "sudo gammy" it works, although i can't close the app nor the terminal.
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' 2021-04-07 16:12:03.242 ERROR [36985] [MainWindow::createTrayIcon@144] Systray unavailable. Closing the window will quit the app.
I am not sure what barrier is, i found this online: https://snapcraft.io/barrier
I don't know what a KVM switch has to do with this problem, but i am using a physical one for my work laptop and my pc.
Ah yes, and it seemed to work at some point but i dont remember when or why it stopped working

@BenjaminJacober commented on GitHub (Apr 7, 2021): Ive got the same problem. Using Linux Pop!_OS 20.10. The https://extensions.gnome.org/extension/615/appindicator-support/ extension is on by default and works well with other applications like Steam or Teams. Running gammy by clicking its icon nothing happens, running it with "gammy" in a terminal results in the same. Only when running "sudo gammy" it works, although i can't close the app nor the terminal. `QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' 2021-04-07 16:12:03.242 ERROR [36985] [MainWindow::createTrayIcon@144] Systray unavailable. Closing the window will quit the app. ` I am not sure what barrier is, i found this online: https://snapcraft.io/barrier I don't know what a KVM switch has to do with this problem, but i am using a physical one for my work laptop and my pc. Ah yes, and it seemed to work at some point but i dont remember when or why it stopped working

No labels

Rows
Columns