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

[fbushstone]

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

[fauxmight]

@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]

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]

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]

@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]

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]

@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]

@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]

@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