Feature request: print current layer

[Kommynct]

Is your feature request related to a problem? Please describe.

I'd like to be able to, in the cli, print the current layer that is active in kanata, so that I can show the current layer on hyprlock.

Describe the solution you'd like.

kanata --print

(or something like that) should tell me the name of the currently active layer, this would also be helpful for scripting.

[jtroo]

You can run Kanata with a TCP server and then connect to get the current layer. Example:

#997 (comment)

[Kommynct]

That is certainly a workaround but tbh that is a very convoluted solution for printing the current layout, i do think that should be a basic command.

[jtroo]

It is the intended use case of the TCP server, not a workaround. How would you expect a command like kanata --print to work behind the scenes?

[Kommynct]

I'd expect kanata to have, in ram, the current layout label, kanata --print would then check for a running daemon, and if it finds one, ask that running daemon (probably with dbus) for the layout, or it could just be stored in a file that can be read on demand rather than broadcasted by the daemon.

Not sure of the security implications.

Alternatively it could setup the tcp server for you, which would also be a lot less work and a lot less confusing.

I'd like to know your thoughts on the matter, though, I don't know anything and i'm just talking out my ass to be clear.

I'm actually struggling quite a bit to figure out how to do that tcp daemon thing, it's just very complex for what should be rather simple. I also think that since this would be handled completely in ram and not using a filesystem that it would be slightly more performant.

[jtroo]

Run kanata with the -p flag. Choose whatever port you like that is available, in this case I chose 12345.

kanata -c sample.kbd -p 127.0.0.1:12345

Example bash command and output:

$ read msg </dev/tcp/localhost/12345; echo $msg | jq .LayerChange.new
"default-layer"

This doesn't feel very complex if you're already planning to do scripting with it.

[Kommynct]

That's mostly acceptable, please leave the issue open, a simpler solution that just uses the layer listed in ram would still be a lot faster and have far fewer moving parts in my eyes (plus doesn't this implementation cause writes to the filesystem, meaning it wears down flash storage?) so it would still be preferred, and i'd update to using it if it existed, but that works, thanks!

[jtroo]

There are no filesystem writes, the path here is a "dummy" kernel path used for opening sockets. Like how /dev/input refers to input devices like keyboards.

"Uses the layer listed in RAM” isn't a meaningful statement for designing an interprocess communication mechanism, which is what a kanata --print command needs to achieve.