[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area with Qt ≥ 5.11
https://bugs.kde.org/show_bug.cgi?id=418891 Nate Graham changed: What|Removed |Added Status|REOPENED|CONFIRMED Summary|Hover effect on toolbar |Hover effect on toolbar |buttons not working after |buttons not working after |dragging window from empty |dragging window from empty |area|area with Qt ≥ 5.11 -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 Nate Graham changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|UPSTREAM|--- --- Comment #9 from Nate Graham --- Looks like this is not an upstream bug after all. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 andi.sch...@me.com changed: What|Removed |Added CC||andi.sch...@me.com --- Comment #8 from andi.sch...@me.com --- Any update on this? Happens whenever dragging from an empty area - hover effects completely stop working until you click inside of the window. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 --- Comment #7 from Tsu Jan --- After a long search in Qt's code and finding no problem in it, I started to get suspicious of the old dragging code of Breeze/Kvantum/QtCurve and, finally, succeeded in replacing it with another code structure that solved the problem in Kvantum, under both X11 and Wayland, and also under all Wayland compositors. Long story short, with Qt ≥ 5.11, the event filter should be installed on QWindow, not QWidget, and the mouse press event of QWindow should be "eaten up" to start the drag (the long story is in the latest git source 'Kvantum/style/drag/windowmanager.cpp'). The same approach can be used with Breeze (and QtCurve). -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 --- Comment #6 from Tsu Jan --- Oh, I'd added a code comment to Kvantum: It started to happen with Qt5.11. Before 5.11, the code worked fine everywhere: Breeze, Kvantum and QtCurve used it with some variations (I think the original code came from QtCurve or Bespin?). I can't report the problem to Qt because they need a code sample to reproduce it and I don't know exactly where the problem is :( If I find the time, I'll try to compare the sources of Qt 5.10 and 5.11. Will add a comment here if I find the cause. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 Nate Graham changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |UPSTREAM --- Comment #5 from Nate Graham --- Yeah, if it happens in multiple widget styles, it's almost certainly a Qt bug. Can you file on on their bug tracker and link it in the URL field of this bug report? Thanks! -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 --- Comment #4 from Tsu Jan --- It isn't related to resuming. You should put the mouse cursor over widgets that have a hover effect (like toolbar buttons). Actually, it isn't limited to Breeze; it happens with QtCurve too. It also happened with Kvantum but I added a workaround for X11 to Kvantum. Sadly, the workaround can't be used for Wayland. I recently added 'QWindow::startSystemMove()' to Kvantum for Wayland and dragging had the same problem under Wayland. I even tried sending enter events to no avail. So, I think the problem should be in Qt. As a matter of fact, it started to happen after a Qt upgrade but I don't remember which version. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 --- Comment #3 from Nate Graham --- Cannot reproduce by dragging. By any chance is this happening after you wake the computer up from sleep? I've recently started to encounter an issue with these symptoms, but it happens after waking up the computer. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 Tsu Jan changed: What|Removed |Added CC||tsujan2...@gmail.com --- Comment #2 from Tsu Jan --- This may be a Qt issue because now, with Qt 5.15, the drag code uses QWindow::startSystemMove() and yet, the problem exists under both X11 and Wayland. The structure of the drag code is very old (a mouse press sends a mouse move event, which triggers dragging under appropriate conditions, and a mouse release event is sent after the drag is finished) but I couldn't find a problem in it. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 --- Comment #1 from Michael D --- Actually the hover effect anywhere on the window stops working, not just on the toolbar. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 418891] Hover effect on toolbar buttons not working after dragging window from empty area
https://bugs.kde.org/show_bug.cgi?id=418891 Nate Graham changed: What|Removed |Added CC||n...@kde.org Status|REPORTED|CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.