[GH-ISSUE #38] Lan-mouse continues to run after exiting GUI with no way to re-open. #11

New issue

Closed

opened 2026-05-05 22:03:20 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 22:03:20 -06:00

Owner

Originally created by @CupricReki on GitHub (Nov 30, 2023).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/38

Lan-mouse continues to run in the background after closing the GUI with no taskbar icon. Adding an option to close/minimize to taskbar would be great.

Wayland
KDE Plasma 5.27.9

Originally created by @CupricReki on GitHub (Nov 30, 2023). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/38 Lan-mouse continues to run in the background after closing the GUI with no taskbar icon. Adding an option to close/minimize to taskbar would be great. Wayland KDE Plasma 5.27.9

gitea-mirror closed this issue

2026-05-05 22:03:22 -06:00

gitea-mirror commented

2026-05-05 22:03:25 -06:00

Author

Owner

@feschber commented on GitHub (Nov 30, 2023):

Yes, I'm aware of this.

The reason, it currently works like this is because I'm not fully decided on whether or not I should split lan-mouse into separate binaries for the Gui and the actual service that talks with the compositor for input emulation / capture. This would however add the extra step of launching the service which I want to avoid.

Ideally it should be transparent to the user such that on first startup the service is started and then keeps running until someone explicitly disables it (you may have noticed that the enable switch does not work yet). Subsequent instances would then only launch the Gui and talk to the service.

This approach would require the background desktop portal or a systemd user service. I'm still figuring out what's best here.

The infrastructure for reattaching the service to a new gui is already in place so bare with me here :)

@feschber commented on GitHub (Nov 30, 2023): Yes, I'm aware of this. The reason, it currently works like this is because I'm not fully decided on whether or not I should split lan-mouse into separate binaries for the Gui and the actual service that talks with the compositor for input emulation / capture. This would however add the extra step of launching the service which I want to avoid. Ideally it should be transparent to the user such that on first startup the service is started and then keeps running until someone explicitly disables it (you may have noticed that the enable switch does not work yet). Subsequent instances would then only launch the Gui and talk to the service. This approach would require the background desktop portal or a systemd user service. I'm still figuring out what's best here. The infrastructure for reattaching the service to a new gui is already in place so bare with me here :)

gitea-mirror commented

2026-05-05 22:03:26 -06:00

Author

Owner

@CupricReki commented on GitHub (Dec 1, 2023):

Seems very logical that there should be a separate systemd service. While the service is running, there should be a taskbar icon as well which launches the GUI.

@CupricReki commented on GitHub (Dec 1, 2023): Seems very logical that there should be a separate systemd service. While the service is running, there should be a taskbar icon as well which launches the GUI.

gitea-mirror referenced this issue

2026-05-05 22:14:37 -06:00

[PR #11] [MERGED] Add full mouse support on windows #228