https://bugs.kde.org/show_bug.cgi?id=499637
--- Comment #11 from Marc Payne <marc.pa...@mdpsys.co.uk> --- (In reply to fhortner from comment #10) > What QTBUG-127122 mentions is: > I can't find out why this signal is not triggered when the mouse enters for > the first time in the MouseArea > > So it could be that when the lock screen is enabled, the MouseArea is > created. > Since the mouse is not really entering the MouseArea but is more or less > already in the MouseArea since creation, this well could an unintentional > regression. > > But to be hones, I have no experience how it coded, it's just an idea. Yes, the MouseArea is essentially being created underneath the mouse pointer so the pointer is already deemed to have entered it. A QEvent::HoverEnter event is fired as a result which I think is reasonable. The change in QTBUG-127122 causes the HoverEnter handler to now emit the positionChanged signal. In the case of the lock screen, the pointer hasn't actually moved but usually a HoverEnter would be occurring as a result of pointer movement and so a positionChanged signal makes sense, which I think was the point being made in the Qt bug report. I'm not sure the Qt Company will be particularly interested in complicating their code to deal with this edge case. If this behavior had been in place from the start, KDE would have needed to work around it anyway. -- You are receiving this mail because: You are watching all bug changes.
