Fix inconsistent floating window z order across outputs

[Nefsen402]

Currently floating windows when appearing across outputs (in a multi-monitor setup) will cover other floating windows unconditionally sometimes even if I try to focus the covered floating window. This happens when a window belongs to say workspace 1. If that window is strung across multiple monitors such that it also covers contents of workspace 2, floating windows in 2 will always be either behind or above floating windows in workspace 1. This makes working impossible sometimes unless you move the windows out of the way.

My fix is to maintain a counter that increments everytime a floating window wants to be shown on top. This counter is shared across the entire seat so that even across workspaces, floating windows maintain the expected z order.

[Nefsen402]

Latest version fixes scratchpad windows not going to top when called upon

[Xyene]

I'm in favour of adopting this behavior, but note:

• The current behavior is what i3 does, even if quirky and unintuitive. I would prefer to diverge from i3 here, but don't know how others feel.
• Use wlroots' scene-graph API #6562 might be a better place to address this, as lots of stacking code will need to be replaced there. Any code we might merge in this PR is unlikely to survive the transition to scene-graph.

@emersion, thoughts?

[Nefsen402]

• Use wlroots' scene-graph API #6562 might be a better place to address this, as lots of stacking code will need to be replaced there. Any code we might merge in this PR is unlikely to survive the transition to scene-graph.

It seems like the proposed plan in the issue tracker would make a global floating window list which would where each floating window would have a reference to its owned workspace so that the proper floating windows would be hidden if the workspace is not in view. This is functionally the same as what is being implemented in this PR, but a bit more robust because there's no chance for a number to overflow, but I don't think that's a problem. A user would need to set a window to be on top 4 billion times before running into problems in the same session.

[Nefsen402]

I spoke with @emersion on IRC, and we seem to be in agreement that the behavior of floating windows as outlined here is okay. This PR however is a hack, and probably shouldn't be merged. I will start working on the port to wlr_scene and the floating window behavior should be mirrored there.

[vyivel]

Superseded by #6844.