XdgToplevelStable: Accept more protocol-compliant behaviour.
We assumed that the compositor would send a second `xdg_surface.configure` after
committing a buffer, as now that the surface is mapped we expect it to be in the
`activated` state.
This second configure isn't guaranteed by the protocol, and there's no reason a
compositor couldn't set the `activated` state in the *first* `configure`, prior
to the window being mapped, on the basis that it'll almost certainly be made active
once it *has* been mapped¹.
Instead of waiting for a second configure, wait for the surface to be in `activated`
state. That catches both, equally protocol compliant, compositor behaviours.
¹: This is possibly desirable behaviour - this way the client can immediately draw
in the activated state, rather than rendering for an inactive window and then immediately
needing to re-render for an active window.
1 file changed
