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

Remove QGuiApplication::mouseButtons()/keyboardModifiers() API

    XMLWordPrintable

    Details

    • Platform/s:
      All
    • Technical Risk:
      Normal

      Description

      The documentation of QGuiApplication::mouseButtons() states - "The current state is updated synchronously as the event queue is emptied of events that will spontaneously change the mouse state (QEvent::MouseButtonPress and QEvent::MouseButtonRelease events)". But internally we have been updating these state variables from various places to keep buttons returned by mouseButtons() in sync with the actual window system state. This is not the documented behavior.

      Why remove? It is an easy to misuse API by:

      Application developers:

      The only place where the values of this API can be trusted is when using within mouse handling callbacks. In these callbacks we work with the state that was provided directly by the windowing system. Anywhere else it might not reflect what user wrongly expects. We might not always receive a matching mouse release for a press event (e.g. When dismissing a popup window on X11. Or when dnd enter Qt application with mouse button down, we update mouse_buttons and then dnd leaves Qt application and does a drop somewhere else) and hence mouseButtons() will be out-of-sync from users perspective, see
      for example QTBUG-33161. BUT THIS IS NOT HOW THE API IS SUPPOSED TO BE USED. Since the only safe place to use this API is from mouse event handlers, we might as well deprecate it and pass down the button state if we are not already doing that everywhere where it matters.

      Qt framework developers:

      We see users complaining, we start adding hacks everywhere just to keep buttons in sync There are corner cases that can not be solved and adding this kind of hacks is never ending task.

      Real mouse events, tablet mouse events, synthesized, etc: all go through QGuiApplication::processMouseEvent, and all share mouse_buttons. What if we want to support multiple mice in future? The API must go.

      Motivation why this API is public is not clear. Could the same be achieved by a user by installing an event filter?

        Attachments

          Issue Links

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

            Activity

              People

              Assignee:
              vhilshei Volker Hilsheimer
              Reporter:
              paeglis Gatis Paeglis
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: