Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-46412

expose a complete list of QInputDevice



    • 6589f2ed0cf78c9b8a5bdffcdc458dc40a974c60 (qt/qtbase/dev), 2a9d93efc (dev), dc7f4f7b4 (dev), 944a94806 (6.5), d48e81f7a (dev), 37c29fca7 (6.6), 8d7476494 (tqtc/lts-6.5)


      *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
            • QTouchScreen
            • QTouchPad
            • QMouse
            • QTablet

      There are several goals:

      1. 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.
      2. being able to associate devices together with a "seat" or "user"
      3. 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.
      4. qtdiag could dump the whole device hierarchy on-demand
      5. 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.


        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.



              srutledg Shawn Rutledge
              srutledg Shawn Rutledge
              2 Vote for this issue
              4 Start watching this issue



                Gerrit Reviews

                  There are 2 open Gerrit changes