Open Shinyzenith opened 1 year ago
@ajanon Hi Alexis, what are your thoughts on this? How do you think we should try implementing this?
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?
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?
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?
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!
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?
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!
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.)?
Note: I think the X11 specific code should be guarded behind a crate feature.
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?
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:
swhkd
is running on and conditionally perform logic such as set repeat rate on X11.Ref: https://github.com/waycrate/swhkd/issues/117 Ref: https://github.com/waycrate/swhkd/issues/76