I feel your language underestimates the scope of the problem. As the blog post itself implies: > The Wayland protocol is by design more constrained compared to

I feel your language underestimates the scope of the problem. As the blog post itself implies: > The Wayland protocol is by design more constrained compared to more traditional display systems like X11 and win32, which brings a unique sets of challenges in the integration of Wayland with Wine. Since Wayland's window model is not based on a single flat 2D co-ordinate space, as X11's was, the Wayland protocol doesn't allow apps to control their absolute position on the screen. Win32 applications heavily rely on this feature, so the Wayland driver uses a few tricks to accommodate many common cases, like transient windows (menus, tooltips etc). It doesn't so much explain what it solved and how, but that it delivered a partial implementation of common cases based on what can be done at this point.