You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To have the same features as Stumpwm, Mahogany needs to have client windows that issue commands to the compositor. Stumpwm does this by creating windows within the same process as itself, which leads to numerous problems that appear hard to overcome in a portable and easy to maintain manner.
Why Use a Wayland Protocol?
From what I can tell, the correct approach is one of two options:
Use a specialized Wayland protocols that clients can use to submit commands. We might be able to find some existing ones for various tasks.
Spin up an client application and listen to its standard output.
From a Common Lisp perspective, using a dedicated Wayland protocol seems like the most portable and maintainable option. This is mostly because we would need to plug into the Wayland event loop using file descriptors or roll our own event loop in order to watch the stdout of the client app. From what I can see, neither of these things are particularly easy to do across Lisp implementations, but I'd be happy to be proven wrong. Moreover, using a Wayland protocol means that there would be a clear specification for how the communication between client and compositor would work, and it should be relatively easy to add features to the protocol if needed.
Protocol Requirements
Independent of what the actual implementation is, we would need to receive the following information from clients:
The name of the command to run. Probably a string.
The arguments to the command, if any. Probably an array of strings that we could then transform into whatever type is required by the command.
As far as what the client would look like in this case, I see it as a one-off application that would take a single command, prompt the user for missing information if needed, submit the command, then exit. I could also see it displaying any errors that resulted when executing the command as well, but we probably should wait to do that to keep things simple.
Background / Previous Work
To have the same features as Stumpwm, Mahogany needs to have client windows that issue commands to the compositor. Stumpwm does this by creating windows within the same process as itself, which leads to numerous problems that appear hard to overcome in a portable and easy to maintain manner.
Why Use a Wayland Protocol?
From what I can tell, the correct approach is one of two options:
From a Common Lisp perspective, using a dedicated Wayland protocol seems like the most portable and maintainable option. This is mostly because we would need to plug into the Wayland event loop using file descriptors or roll our own event loop in order to watch the stdout of the client app. From what I can see, neither of these things are particularly easy to do across Lisp implementations, but I'd be happy to be proven wrong. Moreover, using a Wayland protocol means that there would be a clear specification for how the communication between client and compositor would work, and it should be relatively easy to add features to the protocol if needed.
Protocol Requirements
Independent of what the actual implementation is, we would need to receive the following information from clients:
The wlr foreign toplevel management protocol could provide some additional insights to how to design such a protocol.
The text was updated successfully, but these errors were encountered: