Details
-
Task
-
Resolution: Done
-
P3: Somewhat important
-
None
-
None
-
6589f2ed0cf78c9b8a5bdffcdc458dc40a974c60 (qt/qtbase/dev), 2a9d93efc (dev), dc7f4f7b4 (dev), 944a94806 (6.5), d48e81f7a (dev), 37c29fca7 (6.6), 8d7476494 (tqtc/lts-6.5)
Description
*QTouchDevice exists already, as a public class, and has some oddities. (Like, why are the setters public?) So, it may be too late (for bincompat reasons) to add QInputDevice as a base class from which QTouchDevice inherits, but we should go in the direction of doing that in Qt 6. The ultimate hierarchy might be something like
- QDevice ?
- QScreen
- QInputDevice
- QKeyboard
- QPointingDevice
QTouchScreenQTouchPadQMouseQTablet
There are several goals:
- behavior might be different depending on device capabilities; e.g. you cannot use Tab for navigating between input fields if there is no tab key: instead you might use arrow keys on an embedded system which has only a 5-way navigation pad or remote control that is masquerading as a keyboard (because of using USB HID, perhaps). And if you have a mouse, then you need wider scrollbars compared to having a touchpad or touchscreen, where scrolling is always done by flicking.
- being able to associate devices together with a "seat" or "user"
- being able to associate touchscreens with (parts of) QScreens, because the touchable surface might be only part of your complete desktop. Given that the UI will be different depending on whether a window is shown on a touchscreen or not, it's not enough to know whether the system has a touchscreen: you need to know whether the window is mapped to the part of the desktop where touch input can reach.
- qtdiag could dump the whole device hierarchy on-demand
- Qt could include a GUI tool which looks similar to Windows Device Manager, showing Qt's view of the devices that it has discovered
So for Qt 5 we can still add QInputDevice, it's just that QTouchDevice cannot yet inherit from it, and QInputDevice will need to duplicate some stuff which is relevant only to certain devices: capabilities, maxTouchPoints, type of keyboard, etc. Every QInputEvent should be able to return a QInputDevice pointer which is its source. That accessor should be called inputDevice() in Qt 5, because QTouchEvent already has a device() accessor, and shadowing the inherited one would be bad form. In Qt 6, the accessor can be renamed to device() and return a QInputDevice. That way maybe we don't need to deprecate anything now, and the API change from 5 to 6 will be minimal.
In addition to getting the device from QInputEvent, there should be some way to get the whole hierarchy, e.g. QGuiApplication::devices() or some such.
It depends somewhat whether each platform can give us this information.
Attachments
Issue Links
- depends on
-
QTBUG-63363 QPointingDevices for the trackpad and mouse are dynamically instantiated on macOS
- Reported
- is duplicated by
-
QTBUG-72167 Add a device tree
- Closed
- is required for
-
QTBUG-101648 On Windows Touch device(Surface Pro) need to know if external keyboard is connected or not
- Reported
-
QTBUG-69433 Support multiple seats (several users with separate screens/mice/keyboards)
- Reported
-
QTBUG-38159 add info about input devices to qtdiag
- Closed
- relates to
-
QTBUG-98344 Support multiple keyboards on x11/xcb
- Reported
-
QTBUG-56115 Cannot associate Window with a (Q)Screen
- Closed
- resulted in
-
QTBUG-119029 Get rid of QXcbConnection::TouchDeviceData; pre-construct QEventPoints in xcb plugin
- Reported
-
QTBUG-85114 decide whether QPointingDevice::primaryPointingDevice() can be a touchscreen
- Closed