Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. mouseMove events go to wrong MDI window when overlapping (Qt5 macOS only)
Forum Updated to NodeBB v4.3 + New Features

mouseMove events go to wrong MDI window when overlapping (Qt5 macOS only)

Scheduled Pinned Locked Moved Solved General and Desktop
3 Posts 2 Posters 295 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • I Offline
    I Offline
    iforce2d_where_is_my_old_account
    wrote on last edited by
    #1

    Years ago I made an application with Qt4.8.2 that uses MDI windows, and everything worked fine. Recently I have been updating it to Qt5.15.2 and found that on macOS when two MDI windows overlap and the mouse location is in the overlapping section, mouseMove events do not always go to the top window.

    After much twiddling around I noticed that the mouseMove focus can be swapped between windows by moving the mouse to a location that has only one window under it. This is a bit tricky to explain in writing so I made a video to demonstrate:
    https://youtu.be/8vgS76czato

    It seems like Qt is looking at the windows under the mouse to decide which should get the move event, but if there are more than one (an overlapping section) it just passes the event to the same window as last time.

    Each MDI window contains a single QGLWidget configured like this:

    setAttribute(Qt::WA_PaintOnScreen);
    setAttribute(Qt::WA_OpaquePaintEvent);
    setAttribute(Qt::WA_NoSystemBackground);
    setAttribute(Qt::WA_ContentsPropagated);
    
    setFocusPolicy(Qt::StrongFocus);
    
    setAutoFillBackground(false);
    setAutoBufferSwap(false);
    
    setMouseTracking(true);
    

    One other factor which might be relevant is the old Qt4 app was 32-bit using Carbon. The updated one is 64-bit and using Cocoa. I'm testing on 10.15 Catalina.

    The problem does not occur on Linux or Windows, and does not affect click or drag events. Is there something new in Qt5 that's necessary to have the same behavior as before?

    1 Reply Last reply
    0
    • SGaistS Offline
      SGaistS Offline
      SGaist
      Lifetime Qt Champion
      wrote on last edited by
      #2

      Hi,

      Did you also check whether it's still the case with Qt 6 ?

      Interested in AI ? www.idiap.ch
      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      0
      • I Offline
        I Offline
        iforce2d_where_is_my_old_account
        wrote on last edited by
        #3

        Thanks for the suggestion.

        Moving my whole app to Qt6 to test that would have been a big job so I started making a minimum reproduction case. Using the examples as a starting point I noticed that they no longer use QGLWidget, instead using the newer QOpenGLWidget. I tried QOpenGLWidget for the minimum reproduction case and it worked ok.

        After modifying my app to also use QOpenGLWidget the mouseMoveEvent problem was solved. This also fixed some janky behavior where the MDI subwindow had not been responding to clicks on the traffic light buttons, and sometimes could not be dragged.

        It seems that QGLWidget remains only as a convenience for older code so is probably no longer being tested.
        https://www.qt.io/blog/2014/09/10/qt-weekly-19-qopenglwidget
        https://doc.qt.io/qt-5/qopenglwidget.html#details

        1 Reply Last reply
        1

        • Login

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • Users
        • Groups
        • Search
        • Get Qt Extensions
        • Unsolved