Ontop client bug

[flyboy14]

When I make an ontop client window fullscreen and then back to non-fullscreen state, it also appears not to be ontop anymore.

[psychon]

This is done on purpose:

awesome/objects/client.c

Lines 1112 to 1119 in cd63cab

	/* become fullscreen! */
	if(s)
	{
	/* You can only be part of one of the special layers. */
	client_set_below(L, cidx, false);
	client_set_above(L, cidx, false);
	client_set_ontop(L, cidx, false);
	}

Alternatively, we would have to define an arbitrary "stronger than" relation between these properties to decide which one is ignored when more than one is active.

[flyboy14]

So, if I understood correctly, client couldn't be both fullscreen and ontop at the same time?

[psychon]

Yup.

Awesome thinks in layers. At the very top are "ontop" windows. Below that come "fullscreen" windows, then "above" windows. Then "normal", "below" and "desktop" (in this order). That's what the comment that I linked to above means with "a window cannot be in multiple layers at the same time". Put differently, a fullscreen client is automatically something like ontop. (However, we do allow clients with type "desktop" to be "ontop" and ignore their desktop property as long as they are ontop, so perhaps something similar could be done here... but would that make sense? I'm not sure)

And yet I also think that this bug report has a valid point (unexpected behaviour, but "it's a feature, not a bug" :-) ).

[blueyed]

@psychon

define an arbitrary "stronger than" relation between these properties to decide which one is ignored when more than one is active

I'd vote for that..

[Elv13]

@blueyed Then we would be better to just implement z-index and emulate the current layers on top of that. Most WMs have those ontop/normal/above/below/desktop layer concepts. Also, I don't mind the current behavior, it work fine for me.

[rogorido]

@flyboy14 this is already closed, and this is only a workaround but it seems to work for me:

client.connect_signal("property::fullscreen",
              function(c)
             if c.class == "mpv" and c.fullscreen == false then
                c.ontop = true
             end
              end)

[blueyed]

@rogorido
For this to work you need to be aware that a client should be ontop after all.

@Elv13

Most WMs have those ontop/normal/above/below/desktop layer concepts.

Sure. But this is about internal implementation, and a simple fix for this might really be to allow having "fullscreen = true" and "ontop = true" set at the same time, but then only use "ontop" for stacking.

Also, I don't mind the current behavior, it work fine for me.

Yes, it is not too bad, but it is really confusing that a "fullscreen" client gets not only tiled suddenly when setting ontop, but also that its fullscreen state is not restored/kept when unsetting "ontop".

I came across this via blueyed/awesome-cyclefocus#26: I am using "ontop = true" temporarily to ensure a client is visible when cycling, and this requires additional handling of the other related properties (fullscreen, above, and below) - not only for the current client, but also others (because you need to unset ontop for others to make fullscreen clients visible).

For reference, this is where the order is used:
https://github.com/blueyed/awesome/blob/57e05cda1c05eeb793973ff214713bf7d2ad48c5/stack.c#L125-L156