Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design (or find) a method for replicating Stumpwm's colon command #33

Open
sdilts opened this issue Oct 13, 2023 · 1 comment
Open

Design (or find) a method for replicating Stumpwm's colon command #33

sdilts opened this issue Oct 13, 2023 · 1 comment

Comments

@sdilts
Copy link
Collaborator

sdilts commented Oct 13, 2023

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:

  • 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.

The wlr foreign toplevel management protocol could provide some additional insights to how to design such a protocol.

@sdilts
Copy link
Collaborator Author

sdilts commented Oct 13, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant