QtWayland Remaining Issues: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
Raw notes
- Wayland has fixed concepts and Qt has its own and they dont match
- Wayland has fixed concepts and Qt has its own and they dont match



Revision as of 12:31, 1 December 2023

- 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