-
-
Notifications
You must be signed in to change notification settings - Fork 20
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
Proposal for wmfocus 2.0 #276
Comments
Interesting proposition. It would certainly allow for easier user-sided extension as long as the window managers allow some kind of export of the desktop tree. I'm not sure the startup slowdown would be noticeable, I think probably not. I don't really see big reasons not to do it like this. I don't personally use Wayland but I hope Cairo works natively with it somehow. I'd much prefer if the rendering system were somehow shared between X and Wayland. That said, is this something you'd like to work on? |
I looked at it a little this weekend, but don't find the Rust/Wayland docs easy to follow, being a beginner at both. As far as I got was the working code I included above to draw a Wayland window, but there are other details I still need to learn, how add text to the window. If I work on this, I'd make a Wayland-only solution. X11 is on life support [1] and major toolkits like GTK are looking at dropping support for it. [2].
Otherwise, the already published STDIN published has already implemented that part. I confirmed this weekend it compiles, runs and works with Sway, while the other author tested it with bspwm. |
Putting my own interest in Wayland aside, even creating a "2.0" based on accepting window details on STDIN would make I could help with that part and Wayland support could be pushed to a later release. |
Here's some refined pseudo-code for
This design removes the idea of compiling different WMs as competing features. The intent is that perhaps only Sway and i3 would get special treatment-- because it's hard to maintain support for a WMs the authors are not using-- and other WMs would use the STDIN API. Also, I found a better example of Rust code to draw windows on Wayland. This uses GTK instead of Smithay, but the code is clear, concise and easy to read, and includes an example of formatting text in a simple window using Pango markup. https://github.com/ilya-zlobintsev/sway-marker/blob/master/src/main.rs |
Someone implemented a tool like this for Sway, so I'll be using that instead: |
Why 2.0?
Building support for multiple window managers has been problematic. Currently, only one can readily be compiled-in at a time. Support for Sway was never merged, and support EWMH-compliant window managers has not been completed either.
The STDIN branch demonstrated how window-manager-specific bits can be externalized, so new window managers can supported without modifying this software.
wmfocus
2.0 can build on that approach, which can both simplify the code base while making it easier to support multiple window managers.Different window managers need different syntax. Support for some popular window managers can be built-in, while it can be easy to document and share configs for others.
This design will require some breaking changes, hence: 2.0.
The Window format to expect on STDIN
The following space-separated line-based format will be expecteds to be received on STDIN:
Here X and Y corresponds to the upper-left corner of windows. Passing the details for visible windows only is expected.
Example:
Native support for popular window managers
If no input is given on
STDIN
,wmfocus
could possibly detect a small number of officially supported window managers and gather the input directly.For example, checking if XDG_CURRENT_DESKTOP=sway to indicate sway is running, and then internally call
swaymsg
to details on stdin.Using a Rust JQ library instead of calling the jq binary would a way to still use the JQ syntax but without adding an external dependency.
https://docs.rs/jq-rs/latest/jq_rs/
The JQ syntax to support
bpswm
using the STDIN patch is as follows, while the i3 syntax would be very close or Sways.Wayland Support
wmfocus 2.0 should support Wayland. Using XWayland to draw windows can result in
wmfocus
getting "stuck" in some cases. Native Wayland windows would solve that. Below is some example code to draw a window on Wayland.The text was updated successfully, but these errors were encountered: