Details
-
Bug
-
Resolution: Fixed
-
P2: Important
-
5.15
-
None
-
0b253e8c595b596f44959d21124887545ab0b021 (qt/qtwayland/dev) 5cba07a66225d6ecedb1d9e952d272e236f30aa8 (qt/qtwayland/5.15)
Description
Run konsole for example in a QML-based compositor. When the mouse is in the terminal area, you have an i-beam cursor. If you move the mouse quickly out of there, you can easily "jump over" the window decorations and end up with an i-beam cursor everywhere else on the whole desktop.
It seems that WaylandCursorItem can only show cursors that Wayland clients have requested. So either it needs to be somehow connected with the cursor that the compositor itself has requested, as a fallback; or else it should be hidden whenever no client is under the mouse, so that the underlying window system cursor (e.g. the EGLFS cursor) can be shown instead. It already has this declaration
visible: cursorItem.surface != null
so it seems maybe the second strategy was the intended one. But the only way cursorItem.surface can be null is at startup, or if cursorSurfaceRequest is emitted when the mouse leaves the client window. That's not happening, so that visible binding stays true forever after you have entered the first client window.
Attachments
Issue Links
- relates to
-
QTBUG-83973 wayland multi-screen compositor example has redundant cursors with multiple eglfs screens
-
- Closed
-