river-status: add keyboard_layout event

[MaxVerevkin]

I'm new to zig and server-side wayland, so please let me know if if there are better ways to do certain things.

sway was used as a reference.

• Simple test client: https://github.com/MaxVerevkin/river-kbd-layout-watcher
• Status bar integration: https://github.com/MaxVerevkin/i3status-rust/tree/river-kbd

[MaxVerevkin]

Test client: https://github.com/MaxVerevkin/river-kbd-layout-watcher

[MaxVerevkin]

Hmm, I guess the event should also contain some kind of input identifier?

[MaxVerevkin]

Should this event be sent when keyboard is created / destroyed?

[MaxVerevkin]

An alternative to this can be a separate protocol extension that exposes input information similar to how wl_output/xdg_output describes outputs. Are there any such extensions already (I couldn't find any)? Any opinions on this?

Edit: I suppose this is covered by #71

[Leon-Plickat]

Edit: I suppose this is covered by https://github.com/riverwm/river/issues/71

I don't think so. My idea was to limit that protocol to devices handled by libinput, because unifying multiple API surfaces into a single protocol seems a bit unreasonable.

[MaxVerevkin]

Right now the event is sent on binding, ~~on keyboard creation and~~ when layout changes. I think it's better so send it when keyboard is destroyed too. Should I add keyboard_destroyed/removed event or just send keyboard_layout_clear?

[ifreund]

I don't think I'm going to accept this feature as part of a river-specific protocol. Other compositors have the exact same issue and it would be better for this to be solved in a compositor-agnostic way if possible.

See for example https://github.com/labwc/labwc/issues/1317

Alternatively, with my plans for a complete window management protocol this information may end up being exposed to the window manager process by river which could then relay it to status bars and the like.

Sorry to keep you hanging on this for so long without a clear decision one way or the other.

[MaxVerevkin]

Other compositors have the exact same issue and it would be better for this to be solved in a compositor-agnostic way if possible.

I absolutely agree.

In the mean time, for anyone interested, I will continue maintaining this branch, until a better solution is designed.