Qt5: Can tooltip popups be prevented from raising the window?



  • This is apparently a change from Qt4 to Qt5. (We're using Qt 5.5.1). When hovering over a GUI control having a Tooltip, at the moment the Tooltip is shown, the window containing that control is RAISED. This is very undesirable, potentially obscuring the window the user is trying to work with, just as a result of moving the mouse out of the way.

    I don't know this to be relevant, but I'd like to mention that we DO like to use the strangely-named Qt::WA_AlwaysShowToolTips widget attribute. Tooltips on visible widgets in a partially obscured window should work (regardless of the window not being the active window).

    Can this "new" (Qt5) window popup behavior be prevented?

    This question was asked, but not addressed, on this stackoverflow.com post (relative to Qt 5.4.2):

    Qt tooltip brings window to front when it is being shown
    http://stackoverflow.com/questions/30801093/qt-tooltip-brings-window-to-front-when-it-is-being-shown

    Thank you in advance.


  • Lifetime Qt Champion

    Hi,

    Fix in progress here.



  • Thanks SGaist, for pointing me to that fix (last November). It looks like this fix (for Qt 5.8) was REJECTED ...

    Change Iad1ca1a3 -- Windows: Don't raise inactive windows when showing a tooltip
    https://codereview.qt-project.org/#/c/177376/
    

    This is for this unresolved bug, reported in May 2014 for Qt 5.3:

    QTBUG-39147: QToolTip still uses Q_WS_* macros
    https://bugreports.qt.io/browse/QTBUG-39147
    

    Does anyone have any hopeful (or otherwise) information about the disposition of this problem?



  • The crux of the bug is apparently, in widgets\kernel\qtooltip.cpp, the QTipLabel can't be instantiated with the client widget as its widget parent -- because that causes the window to raise when the tooltip is shown. I believe the problem is that the prior fixes tried to make use of the application's desktop's screen widget as the parent, and that apparently results in an effective memory leak.

    https://codereview.qt-project.org/#/c/177376/

    0_1500397993463_Qt551-widgets-kernel-qtooltipB-QtBug39147.png

    We need to apply a fix to Qt 5.5.1. (We are using the HTML DOM API in QWebKit, so it's going to be a big deal for us to move beyond Qt 5.5.1. But this bug isn't even fixed yet in Qt 5.9).

    Does anyone have a sense about "how bad" the leak is? If it's pretty close to negligible, we could live with that, and just use the attempted fix (which had failed a unit test -- the memory leak I mentioned above (if I'm understanding correctly).


  • Lifetime Qt Champion

    That class is a singleton, so there shouldn't be a leak.



  • I guess if there had been concern of a leak, that was apparently a false positive of a unit test. (I'm not sure about this detail).
    This has been resolved, as of today. Here is a summary:

    This bug originally appeared in Qt 5.0, was reported in Qt 5.3.0 (QTBUG-39147), and fixed for Qt 5.9.2 (on 7-19-2017). The removal of Qt_WS_* macros (replaced with Q_OS_* macros), and incomplete porting of the widgets/kerna/qtooltip.cpp module, caused the QTipLabel to be instantiated with the client widget as its parent widget. That had been a known problem on Windows which directly caused this dysfunction (Showing a tooltip raises the whole window).

    See "Patch Set 6" in this Qt code review page, and it's associated "gitweb" link, and the original bug report:

    https://codereview.qt-project.org/#/c/177376/
    https://bugreports.qt.io/browse/QTBUG-39147


Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.