Commit ae9639f7 authored by Fabian Vogt's avatar Fabian Vogt
Browse files

Fix informing the underlying widget when leaving SplitterProxy

While the SplitterProxy is active, it intercepts all relevant events, so that
the underlying widget still thinks it's in the same "on splitter" state. When
the SplitterProxy is left, the underlying widget is sent a HoverLeave/HoverMove
event to make it aware of the new current cursor position. Without this, it
doesn't know that it's not supposed to be in the "on splitter" state, and when
it regains focus it just re-activates the SplitterProxy at the current cursor

This was broken by accident in d201a1f1 ("Fix SplitterProxy not clearing
when above another QSplitterHandle"), which moved the hide() call past the
call to QCoreApplication::sendEvent. Previously that made isVisible() false,
which also prevented the interception of the HoverLeave/HoverMove events.

BUG: 436473

(cherry picked from commit f99b7ef6)
parent cc95dab9
...@@ -355,11 +355,14 @@ namespace Breeze ...@@ -355,11 +355,14 @@ namespace Breeze
// send hover event // send hover event
if( _splitter ) if( _splitter )
{ {
QHoverEvent hoverEvent( // SplitterProxy intercepts HoverLeave/HoverMove events to _splitter,
qobject_cast<QSplitterHandle*>( ? QEvent::HoverLeave : QEvent::HoverMove, // but this is meant to reach it directly. Unset _splitter to stop interception.>mapFromGlobal(QCursor::pos()), _hook); auto splitter = _splitter;
QCoreApplication::sendEvent(, &hoverEvent );
_splitter.clear(); _splitter.clear();
QHoverEvent hoverEvent(
qobject_cast<QSplitterHandle*>( ? QEvent::HoverLeave : QEvent::HoverMove,>mapFromGlobal(QCursor::pos()), _hook);
QCoreApplication::sendEvent(, &hoverEvent );
} }
// kill timer if any // kill timer if any
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment