Does not overlay correctly with KDE

[Melechtna]

I'm simply making a note that it doesn't layer correctly with KDE, however, I'm 90% sure that, like with resolutions higher than 1080p, this can be overcome with wmctrl, I'll report back once I've worked out how to do it, it should also theoretically work with any DE, however I'm unsure if wmctrl works properly with wayland as of yet.

[AsherGlick]

Does your issue seem related to https://github.com/AsherGlick/Burrito/issues/23#issuecomment-899106153?

[Melechtna]

Does your issue seem related to #23 (comment)?

Not directly, though it may be related, the issue more seems to come from the fact that, when I click on the game window, instead of remaining ontop like it should, the game takes priority unless I force it to be behind everything and hide my taskbar. Unfortunately, it looks like some heavy regex would be needed with wmctrl to get it to work, and I'm not entirely sure how to handle that.

[coderedart]

do you mean in windowed fullscreen, or just windowed mode? right now, that is the expected behavior in windowed fullscreen, and there's been some effort going on to make it stay above gw2. but with windowed mode, it should stay on top unless you are using gnome 4.0 .

what versions of plasma/distro are you using btw?

[Melechtna]

do you mean in windowed fullscreen, or just windowed mode? right now, that is the expected behavior in windowed fullscreen, and there's been some effort going on to make it stay above gw2. but with windowed mode, it should stay on top unless you are using gnome 4.0 .

what versions of plasma/distro are you using btw?

I'm using windowed fullscreen, using windowed is...just no, 5.22.0/Arch. I have an NVIDIA card, so, wayland might as well not exist for me for now. I can make it stay ontop using the somewhat janktastic methods I've mentioned.

[coderedart]

yeah, same setup as mine. if you are okay with it, you can try the latest master branch of burrito. we definitely need someone to test the latest changes from https://github.com/AsherGlick/Burrito/issues/25 . i have some issues, but can't figure out if its just me installing multiple DEs or an issue somewhere in the code itself.

[AsherGlick]

FYI If you want to test an untagged commit (like HEAD) without building it yourself, the testing build artifacts stay for 7 days. Just click on the newest run from this page https://github.com/AsherGlick/Burrito/actions and scroll down to "Artifacts".

[Melechtna]

FYI If you want to test an untagged commit (like HEAD) without building it yourself, the testing build artifacts stay for 7 days. Just click on the newest run from this page https://github.com/AsherGlick/Burrito/actions and scroll down to "Artifacts".

I have absolutely no issues compiling it myself, however, there's no instructions for what's required, and I've never compiled a godot binary before, so the source structure is foreign to me.

Edit: I've muddled through to the export step, downloaded the 3.3.3 template, but when I go to export it tells me that the "Export template for this platform are missing/corrupted: Linux/X11"

Edit2: It looks like it compiled fine anyway?

Edit3: even with the debug binary, while it is more obstinate about staying ontop, the problem actually just gets worse, because I can't click anything under it now (other than the game itself) and giving the game focus creates the same problem, because it will still take priority for some reason.

[AsherGlick]

Glad you were able to get things compiled. Godot generates bytecode and injects it into precompile binaries, the export templates, so I am not sure how it could have worked without them but if it works it works.

For your third edit I wonder if it is related to burrito setting "always on top" even while gw2 is not focused. This would mean that if

• you have three windows gw2, burrito, and some third window
• you try to alt-tab to some third window
• burrito is still overtop some third window so when you try to click on it burrito captures the input and refocuses gw2

When burrito has a red border around it it is capturing all mouse inputs in the area, #4 and #5 hope to make that UI a little more intuitive.

Does that describe remaining the issue you are having or am I misunderstanding?

[Melechtna]

Glad you were able to get things compiled. Godot generates bytecode and injects it into precompile binaries, the export templates, so I am not sure how it could have worked without them but if it works it works.

For your third edit I wonder if it is related to burrito setting "always on top" even while gw2 is not focused. This would mean that if

• you have three windows gw2, burrito, and some third window
• you try to alt-tab to some third window
• burrito is still overtop some third window so when you try to click on it burrito captures the input and refocuses gw2

When burrito has a red border around it it is capturing all mouse inputs in the area, #4 and #5 hope to make that UI a little more intuitive.

Does that describe remaining the issue you are having or am I misunderstanding?

Not even slightly, whether I have the menu pulled up or not, with the git pulled version, it would block all input regardless of their title, with the EXCEPTION of the game itself.

[AsherGlick]

@Melechtna #39 has been merged to allow a dynamic screensize. It was mentioned previously that fixing this issue may fix an underlying cause of this issue. Can you confirm that the problem persists with the most recent upstream build now that no workarounds should be needed for larger screen sizes.

[jmetzmeier]

I have the same issue where I am unable to get the overlay to display over top of the game on KDE. I tried the latest from the master branch, but the overlay stil

lt runs behind the game in windowed fullscreen, even after missing with "always in front" and "aways behind" window settings. When running in windowed mode, the overlay does display on top, but it completely covers up the game. Should the background be transparent instead of black? Screenshot attached. I use proprietary nvidia drivers.

[AsherGlick]

Got it, the stacking seems still relevant to this issue. However the black background seems unrelated. Can you open a new issue for it. I am guessing it is that KWin compositing is disabled on your system.

[jmetzmeier]

I do have compositing enabled, but there was a warning saying the opengl compositor had crashed and it fell back to xrender. Re-enabling the opengl compositor doesn't change the black background behavior.

[jasperro]

I got the overlay to work in KDE Wayland by pressing Alt+F3 when burrito is focused, Go to More actions > Configure Special Window Settings > Add Property > Accept Focus. Now set the accept focus to Force and No. Only thing missing in this case is a minimize button for burrito, but minimizing gw2 works too. To change settings of burrito, just alt-tab.

@AsherGlick Maybe possible to set the kwin rule dynamically in godot with OS.execute?

[AsherGlick]

@jasperro I am glad to hear that there is a method to get this to work on KDE Wayland. I generally want to avoid using OS.execute unless there is no other option, eg: if there is a low level c API to address these settings instead. But if there is a real need for this to be automatically set within burrito then a check to make sure that it is only being called on KDE systems will also need to be added. In the meantime maybe adding this info to some documentation would suffice.

[jasperro]

@AsherGlick Maybe something like the org.kde.KWin DBus api can do this? But it is just a few clicks and a one time setting, so probably just a good idea to add it into the documentation in the meantime. It can be imported with a .kwinrule file as well, this should work:

[Window settings for burrito]
Description=Window settings for burrito
acceptfocusrule=2
clientmachine=localhost
title=Burrito (DEBUG)
wmclass=burrito
wmclasscomplete=true
wmclassmatch=2

I've been looking at the wayland protocols, and it seems that Burrito could be implemented with the wl_layer_shell like in https://github.com/junglerobba/wlsplit and the wl_surface::set_input_region protocols possibly, but that depends on godot having wayland support so that is maybe a future possibility. The set_input_region at least seems to be fully implemented in mutter, wlroots and KWin, but wlr-layer-shell only in wlroots and KWin.

[Melechtna]

Got it, the stacking seems still relevant to this issue. However the black background seems unrelated. Can you open a new issue for it. I am guessing it is that KWin compositing is disabled on your system.

I fixed this using picom, I forgot to come back here and mention this, and setting up proper layering in KDE. Wayland however, this is still a complete mess as Jasperro mentioned.