On Capturing the release events of modkeys using X11 2

So, we got it kind of working. While the final solution hopefully employs the now soon-to-be usable term lib I did in my spare-time (Uncharming-Tui), i found that solving the problem thoroughly (overengineered?) would have to employ our beloved divide-and-conquer strategy.

If we observe the problem at hand closely we find there are two quite different problem domains at hand: on one side we have the ways of controlling a computer, the other aspect is about visualization. I was actually mit der nase darauf gestoßen, because I wondered which vehicle would be best to use for visualization, and I found I was lacking some protocol that would allow me to instruct an arbitrary menu-visualization solution to perform some basic operations:

• show options
• hide options
• highlight element
• deselect element

thats about it. as such we typically fall back to old client server model, which in turn, for me, translates to: Unix Sockets. To reiterate: We will have some server I came up with at least two feasible solutions.

1. Extending rofi with facilities for remote controls using its plugin interface (thought this would not take such drastic measures)
2. Using the urxvt interface allowing some arbitrary terminal operation, and hooking my terminal library to it allong with some i3 (display environment) shenanigans

Using Rofi

You find some working solution <u>here</u>. actually i was a bit disappointed about me being the first entity on the interwebs having the demand for remote controlling some rofi instance. Et voila, an extension to rofi i coined: rofi-unix-sockets (whey descriptive names):

// Trait for socket menu functionality, parameterized over types that implement MenuBehavior
pub trait SocketMenu<T: MenuBehavior + Send + Sync + Clone + 'static> {
    fn behavior(&self) -> &T;
    fn socket_path() -> &'static str;

    fn init_socket(&self) {
        let listener = UnixListener::bind(Self::socket_path()).expect("Failed to bind to socket");
        for stream in listener.incoming() {
            match stream {
                Ok(stream) => {
                    let behavior = self.behavior().clone();
                    std::thread::spawn(move || {
                        handle_client(stream, behavior);
                    });
                }
                Err(e) => eprintln!("Failed to accept connection: {}", e),
            }
        }
    }
}

Using Urxvt + Uncharming Tui

Listening on the modkey

Whats left is some rumpfimplementation of some service (we pretty much sketched in the previous article) hooking into X11 (sorry wayland) to listen on mod- (or actually any) key events. As such we'd like to design this in some configurable fashion (yml).

I just hope that there won't be no further unpredictable side effects of hooking into X11 on a layer so deep that we can reliably act on the release event: