[feature] swhks env var synchronization sequence with swhkd

[Shinyzenith]

If an initiation sequence takes place between the client and the daemon then we can synchronize environment variables into swhkd.

This has multiple benefits in code such as:

• Parse environment variables in the config file.
• Check the environment swhkd is running on and conditionally perform logic such as set repeat rate on X11.
• Resolve ~/.config/swhkd/swhkdrc instead of /etc/swhkd/swhkdrc for default config file detection!
• etc.

Ref: #117
Ref: #76

[Shinyzenith]

@ajanon Hi Alexis, what are your thoughts on this? How do you think we should try implementing this?

[ajanon]

I feel like ideally we could have bidirectional communication between sxhkd and swhkd, and swhkd could then request environment variables values only when needed at runtime, but this may add much more complexity.

I am not very familiar with the IPC system we have, so this may be completely off. What do you think?

[Shinyzenith]

bidirectional communication between sxhkd and swhkd

Do you mean swhks and swhkd?

when needed at runtime, but this may add much more complexity

In my opinion swhks is a fairly trivial program, we just have a socket that we write commands to, it's nothing more than that,

A simple if check for a specially crafted message for requesting environment variables will take little to no effort I believe?

[ajanon]

bidirectional communication between sxhkd and swhkd

Do you mean swhks and swhkd?

Yes, that was a typo.

when needed at runtime, but this may add much more complexity

In my opinion swhks is a fairly trivial program, we just have a socket that we write commands to, it's nothing more than that,

A simple if check for a specially crafted message for requesting environment variables will take little to no effort I believe?

Would you mind taking a shot at implementing this if/when you have some time on your hands then?

[Shinyzenith]

A simple if check for a specially crafted message for requesting environment variables will take little to no effort I believe?

Would you mind taking a shot at implementing this if/when you have some time on your hands then?

Absolutely!

[Shinyzenith]

While attempting to write a PoC for this a peculiar question came to mind: What if we want to resolve $TERMINAL variable from the config file during execution? Should this be done on swhks side after parsing out the command and looking for environment variables? Or should this be done in the daemon itself after config parsing?

[ajanon]

The way I see it, the daemon should have as little information as necessary. This decreases complexity in the low level parts of the stack on the privileged process.

You mentioned something interesting: instead of parsing the config in the daemon, couldn't we parse the config in the server? This would mean replacing $TERMINAL in the server, as you suggested. I think this would make it much easier to implement things such as #117, #165 and this would decrease the amount of privileged code.

Going further with this: could we pass a message from the daemon to the server for some additional commands? For instance, instead of changing X11 rates inside the daemon, we could just pass it to the server which has all the information it needs available readily. Reloading the config could be similar: instead of having special code in the daemon, we could tell the server to load it and to pass the information back.

This may not be what you had in mind. Feel free to discuss or criticize this!

[Shinyzenith]

Yep this works too! we can totally parse the config file in the server and send it back to the daemon according to specially crafted messages.

I was thinking of a format such as swhkd:manifest_require_config or swhkd:manifest_require_variable:(TERMINAL).

Do you think this format is clear and concise? We can work on the X11 rate adjustment in swhks too (swhkd:poll_x11_repeat_rate then set the rate returned by swhks after uinput device creation using x11rb.)?

[Shinyzenith]

Note: I think the X11 specific code should be guarded behind a crate feature.

[ajanon]

The message format looks good to me!

I agree with you for X11: no need to build this for people who will be using wayland exclusively.

I just wondered something after thinking about it: could we load the config in the opposite order?

As in, have swhks send the config by itself to swhkd instead of swhkd asking for a config reload (and moving the SIGHUP handling code into swhks too). That way, solving issues such as #175 becomes trivial.

What do you think?