QtWayland Remaining Issues: Difference between revisions
(Created page with "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 ava...") |
No edit summary |
||
| Line 2: | Line 2: | ||
- 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 | ||
- For instance positioning of popups: tooltips, comboboxes, menus, and basically any QWindow which can be a transient child of another window | - 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 | - 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 | - In Wayland there is semantic positioning, anchoring, adapting to available real estate | ||
- Information is in Qt, but not available through QPA | - Information is in Qt, but not available through QPA | ||
- There is a patch, but it is scary because many platforms are affected | - 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 | - Could introduce the new thing first for Wayland only and keep the old and gradually migrate | ||
- Public APIs may also be affected | - Public APIs may also be affected | ||
- Could it be done in QPA first with no public | - 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 | - 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 | - We dont need public API for the fallback logic | ||
- Platform header additions needed because different types of popups need different behavior | - Platform header additions needed because different types of popups need different behavior | ||
- PopupWindowPositioningDescriptorHelper? | - 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 | |||
- This is a problem we have on all platforms actually | |||
- | - | ||
Revision as of 12:18, 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
- This is a problem we have on all platforms actually
-