-
Notifications
You must be signed in to change notification settings - Fork 14
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
Wayland support #20
Comments
It "should" work in theory, but I haven't gotten it to work in my rudimentary tests. (I don't use Wayland day-to-day.) All of the windowing operations in hudkit use GTK3 currently, which has a Wayland backend in addition to X11, and doesn't document having any relevant platform limitations. But it seems there are many undocumented limitations, because running hudkit in Perhaps the limitation is in weston, and a proper full Wayland desktop would work? I haven't tested one. If you want to test it, you should be able to run the example as per the readme, without changes. If it doesn't work, try Technical notes on feasibility of future upgrade to GTK4It seems the idiomatic way to make an overlay window on Wayland, as used by https://github.com/francma/wob, is an unstable Wayland protocol feature "wlr-layer-shell-unstable-v1". I don't know if there are alternatives, or what GTK3/GTK4 use to implement e.g. I would really rather rely on GTK than add platform-specific code paths. If GTK says it has a Wayland backend, but can't actually do the same thing on Wayland as on X11, that's a GTK limitation that should be fixed in GTK. Currently-unstable I would like to stick to the stable WebKit API for ease of maintenance; the previous unstable |
I can test w/ a few representative examples of Wayland envs: KDE Plasma & Sway (wlroots-based compositor). Enough to see what might be needed, or might not be needed (hopefully). Gimme a little and I'll set it up. |
For me it generally seems to work on wayland (KDE Plasma 6 in this case) but the position is off, which might be due to my displays using different resolutions and I don't understand how i can make the overlay window smaller and move it to sa specific location, which would be my usecase to use it as a DPS meter overlay for the game... |
The GTK documentation on `gtk_window_move` [1] state this: > Asks the window manager to move window to the given position. Window > managers are free to ignore this; most window managers ignore requests > for initial window positions (instead using a user-defined placement > algorithm) and honor requests after the window has already been shown. That may be what causes the overlay to the positioned wrong in #18 and #20 (comment). In any case, it should do no harm to make sure. [1]: https://docs.gtk.org/gtk3/method.Window.move.html
@cptn-cosmo Thanks for testing this. I am pleasantly surprised that it works even that well. I want to fix that bug and support your use-case. The detected monitor coordinates shown in the top-left debug information look correct to me, so the fault must be with how the overlay is being positioned. It is positioned based on the same monitor coordinates though, which are correct… My first suspicion is that something else moves the window after it positions itself. I remembered reading in GTK docs that some window managers ignore window move requests until after the window becomes visible, instead doing their own "smart" window positioning. So I added (024bfb6), which tries to reposition the window correctly again after the window becomes visible. Could you test again with that change included? It's on the |
Same problem for me on two monitors with the same resolution, so that is not the problem, also happens with 024bfb6 applied |
Not sure if it's just a KDE Wayland specific issue, but there's a KDE specific workaround, you can just add a Window Rule for hudkit. These settings spawn it at the top-left corner as expected, and make sure it stays as an overlay on top of everything else, doesn't have a border or titlebar, and it doesn't show up on the taskbar or when alt+tabbing. |
I have a different issue as well. I can get the overlay to act as an overlay using the rules @redeven posted, but I can't click on any button in the overlay, like allowing audio access. On FFXIV raiding overlays I also can't click the settings buttons on them. Additionally, I can't figure out how to resize or position any of the overlays. For example, DPS meters for FFXIV are stuck taking up the whole screen and I can't figure out how to make it smaller. More people are going to come looking for wayland support as multiple major distros are now defaulting to it on all GPUs. |
Hi, I just tried the example on Sway with a multi-monitor setup, and there are a few issues:
Here's a screenshot showing my screen layout and how hudkit opens (when launching from the central monitor): |
I'm looking to use a Wayland-based DE/compositor in the future over X11, and I'm what barriers there would be to using HUDKit on Wayland. Has this been tested?
For context, IINACT recommends HUDKit for overlays on Linux, and I want to make sure this works as well without having to go and use an X11-based environment.
The text was updated successfully, but these errors were encountered: