Open mhantsch opened 4 months ago
This request sounds pretty reasonable, but I see some problems with it:
One is that, we can't control start/stop/pause of the external instance (as simply). "pause" and "stop" works by killing kanata process. If we tried to kill external we don't know if it won't be restarted by that externally too.
Being unable to stop external kanata, means that allow_concurrent_presets = false
won't work, because when switching presets, "switching" is basically killing one kanata instance and starting another.
@rszyma What if you made an 'external kanata' mode where some of the functionality is not available? I don't intend to start/stop/pause or switch presets. I just use kanata-tray to visualise the current layer.
I'm don't see this worth adding over added complexity, unless there's a good reason. Why not run system service for kanata-tray instead?
Would kanata-tray run even if the user is not logged in yet (and there is no tray yet)? My kanata service starts quite early in the boot process, so I already have its keyboard remapping available at the login prompt.
Currently? I'm not sure, maybe it would run I haven't tried.
I already have system services configured to start up kanata on system boot.
I would like to add kanata-tray to connect to the already running instance instead of trying to start its own kanata.
I currently worked around this by creating and configuring a fake kanata executable which doesn't do anything and never returns. Kanata-tray now happily starts the fake executable, and then proceeds to talk to the tcp port of the already running real kanata.
Would be great if that configuration could be simplified.