github-starred/barrier

Fork 0

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

[GH-ISSUE #347] How to launch client through systray #279

New issue

Open

opened 2026-05-05 05:55:10 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 05:55:10 -06:00

Owner

Originally created by @ghost on GitHub (Jul 1, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/347

Use case:

Autostart barrier tray icon
Have script running and poll for event:
a) Machine plugged in to docking station - if barrier client not started, start it
b) Machine unplugged from docking station - if barrier client started, kill it

Currently this is possible, however without monitoring from GUI. GUI client runs completely separately and is unaware of a second instance of barrier client. This leads to two problems:

Killing barrier client, the child proccess of barrier GUI, results in barrier GUI restarting the process.
Spawning a new barrier client does not get registered with the barrier GUI, which is unaware of this instance.

Ideally, the GUI would allow some way to emulate the user action of selecting start/stop service from the tray icon. Unix domain sockets? TCP sockets? DBUS? Something to that effect.

I am aware that automation can be achieved with the barrierc client alone, however the tray icon application cannot be presently made to work with this scenario.

If the devs specify which IPC method would be suitable for this task, if any, I might do a POC.

Originally created by @ghost on GitHub (Jul 1, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/347 Use case: 1) Autostart barrier tray icon 2) Have script running and poll for event: a) Machine plugged in to docking station - if barrier client not started, start it b) Machine unplugged from docking station - if barrier client started, kill it Currently this is possible, however without monitoring from GUI. GUI client runs completely separately and is unaware of a second instance of barrier client. This leads to two problems: 1) Killing barrier client, the child proccess of barrier GUI, results in barrier GUI restarting the process. 2) Spawning a new barrier client does not get registered with the barrier GUI, which is unaware of this instance. Ideally, the GUI would allow some way to emulate the user action of selecting start/stop service from the tray icon. Unix domain sockets? TCP sockets? DBUS? Something to that effect. I am aware that automation can be achieved with the barrierc client alone, however the tray icon application cannot be presently made to work with this scenario. If the devs specify which IPC method would be suitable for this task, if any, I might do a POC.

gitea-mirror added the

labels 2026-05-05 05:55:10 -06:00

gitea-mirror commented

2026-05-05 05:55:17 -06:00

Author

Owner

@shymega commented on GitHub (Aug 14, 2019):

With regards to a IPC method, I would, personally, go for something efficient and portable.

We could use Unix domain sockets for the *nix targets, including macOS. With Windows, there's a IPC method called 'Windows Sockets', which might be suitable.

@shymega commented on GitHub (Aug 14, 2019): With regards to a IPC method, I would, personally, go for something efficient and portable. We _could_ use Unix domain sockets for the *nix targets, including macOS. With Windows, there's a IPC method [called][sockets] 'Windows Sockets', which might be suitable. [sockets]: https://docs.microsoft.com/en-us/windows/win32/ipc/interprocess-communications#using-windows-sockets-for-ipc

No labels

Rows
Columns