QtWayland Remaining Issues: Difference between revisions
No edit summary |
No edit summary |
||
| Line 34: | Line 34: | ||
- Other thing: In Wayland setting properties/state for a surface is atomic, which gets in trouble with a render thread | |||
- 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 a buffer with the old size | |||
- This is a problem we have on all platforms actually | - This 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 | |||
Revision as of 12:30, 1 December 2023
Raw notes
- 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 a buffer with the old size
- This 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