QtWayland Remaining Issues

- Wayland has fixed concepts and Qt has its own and they dont match

- For instance positioning of popups: tooltips, comboboxes, menus, and basically any QWindow which can be a transient child of another window

- The client doesnt know where the screen is and the compositor doesnt know how to adapt, it doesnt have the semantic information

- In Wayland there is semantic positioning, anchoring, adapting to available real estate

- Information is in Qt, but not available through QPA

- There is a patch, but it is scary because many platforms are affected

- Could introduce the new thing first for Wayland only and keep the old and gradually migrate

- Public APIs may also be affected

- Could it be done in QPA first with no public

- Not sure this should have public API: Only relevant for tooltips, which has an anchor rect already, so maybe its covered

- We dont need public API for the fallback logic

- Platform header additions needed because different types of popups need different behavior

- PopupWindowPositioningDescriptorHelper?

- Fallback logic should be something the QPA plugin decides based on the type of popup

- In a RTL language, the semantics may be flipped. We know the directionality of the locale language, but not necessarily of the language in the combobox

. Go more semantic: Dont provide instructions, but give a rectangle and information about what it means

- Other thing: In Wayland setting properties/state for a surface is atomic, which gets in trouble with a render thread which may be rendering into and comitting a buffer with the old size

- On NVIDIA drivers, you can run into a crash bug which is probably a driver bug

- On very strict compositor, they can refuse to render your window because it detects a non-compliant client

- Resizing synchronization is a problem we have on all platforms actually

- Can we delay the reply? The problem is that we can't detect on the main thread

- Can we throw away the frame if the size changed? That has been done on other platforms but also causes some problems

- RHI has beginFrame/endFrame which might be useable, but we cant depend on those being called in a custom renderer

- Another case: When you move a window with an item anchored to it, then it will lag behind now, but it should be exact

- We need a follow-up meeting in January with relevant people to find a solution to the general cross-platform problem of resizing while rendering is happening

- For the crash on NVIDIA we will look into hotfixing this with beginFrame/endFrame, which could be temporary if we find a general solution