search

djpohly / dwl

dwm for Wayland - ARCHIVE: development has moved to Codeberg
https://codeberg.org/dwl/dwl
Other
1.93k stars 280 forks source link

Make sure that background does not spawn in front of fullscreen clients #487

Closed fbushstone closed 1 year ago

fbushstone commented 1 year ago

I think it would be a good idea to document what exactly fullscreen_bg does. I'd spent the past few hours trying to figure out why SDL apps such as Quake and Xonotic were hidden behind a gray screen while the glx version of Xonotic works fine. Like the config file says, changing the alpha value to 0.0 solves this issue. Maybe something such as: "If fullscreen SDL apps are covered by a solid color, change this to 0.0." Although, maybe I should read the XDG protocol :smile:.

fauxmight commented 1 year ago

@fbushstone This sounds reasonable. I am not among the devs for dwl, but your suggestion might be quicker implemented with a pull request.

EDIT: Unnecessary apostrophe excised (with vehemence).

fbushstone commented 1 year ago

Yes, although I suppose this issue could be a discussion on whether to remove this option as well (making it internal only). No other Wayland compositor I tested had this feature (too intentional to be a bug) and I'm not sure what it's used for.

sevz17 commented 1 year ago

I think it would be a good idea to document what exactly fullscreen_bg does. I'd spent the past few hours trying to figure out why SDL apps such as Quake and Xonotic were hidden behind a gray screen while the glx version of Xonotic works fine. Like the config file says, changing the alpha value to 0.0 solves this issue. Maybe something such as: "If fullscreen SDL apps are covered by a solid color, change this to 0.0." Although, maybe I should read the XDG protocol 😄.

Err... the behavior you mentioned is a bug, the gray screen should be behind fullscreen apps, not the other way around.

Respecting the "old behavior": the protocol says:

    If the surface doesn't cover the whole output, the compositor will
    position the surface in the center of the output and compensate with
    with border fill covering the rest of the output. The content of the
    border fill is undefined, but should be assumed to be in some way that
    attempts to blend into the surrounding area (e.g. solid black).

    If the fullscreened surface is not opaque, the compositor must make
    sure that other screen content not part of the same surface tree (made
    up of subsurfaces, popups or similarly coupled surfaces) are not
    visible below the fullscreened surface.

dwl ignored that for a long time and rendered other apps behind fullscreen windows, that's why setting the alpha to 0 restores the old behavior (it "renders" an invisible solid color, which is the same to render nothing) and it's an option because it's pretty useful with transparent terminals

sevz17 commented 1 year ago

@fauxmight

... I am not among the devs for dwl ...

Hmm, if not for the fact that I can't add other collaborators and that I haven't had time to properly migrate the repo to an organization I would have already asked you to became a maintainer (I know you don't know to program (or have you learned?), but I take your comments into account and think you would do a great job managing issues)

fbushstone commented 1 year ago

Looks like the you can bypass this by toggling fullscreen twice. Not sure why that works but if you launch in fullscreen mode it's obscured. Theoretically, there should be no difference.

fbushstone commented 1 year ago

@sevz17 After poking around for a few hours it seems like the fullscreen rectangle is always where it should be (the beginning of the scene's node list). Would it make any sense to go the xdg_decoration route? It seems like other compositors use this protocol for their server side decorations and could provide a reliable background (as well as do other cool things like enable SSD status bars).

pm4rcin commented 1 year ago

@fauxmight

... I am not among the devs for dwl ...

Hmm, if not for the fact that I can't add other collaborators and that I haven't had time to properly migrate the repo to an organization I would have already asked you to became a maintainer (I know you don't know to program (or have you learned?), but I take your comments into account and think you would do a great job managing issues)

Is there something we could do to help you with that or you just need to sit down and do this?

sevz17 commented 1 year ago

@fauxmight

... I am not among the devs for dwl ...

Hmm, if not for the fact that I can't add other collaborators and that I haven't had time to properly migrate the repo to an organization I would have already asked you to became a maintainer (I know you don't know to program (or have you learned?), but I take your comments into account and think you would do a great job managing issues)

Is there something we could do to help you with that or you just need to sit down and do this?

I appreciate the intention, unfortunately only @djpohly can transfer the repo to an organization. If he doesn't wake up from his hibernation I think I'll have to "create" a new repo w/o all the issues and PRs