| hpereiradacosta |
| Plasma |
Use window manager to handle window move when dragging from free space
also with QtQuickControls.
Registering the QQuickItems is hacky, because there is no Style::polish
for QtQuickControls, so those items are now registered from ::isQtQuickControl.
Works on both X11 and Wayland. Tested with discover and plasma config dialogs
(there it needs to remove the MouseEventListener that also implements window moving).
Also works fine with QQuickWidget in KCM.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
apart from being hacky: very nice! I would not have thought that this is possible at all.
in principle, no objection to the patch, but (big but): breeze style is supposed to compiled and be used against both qt4/kde4 and kf5, this as long as we still have kde4 applications around
There is an option (-DUSE_KDE4=true) in the CMakeLists to test that. (and quite some #if BREEZE_USE_KDE4 in the code)
This patch completely breaks kde4 compilation: there is no QQuickItem in Qt4, nor QWindow (so that all changes QWidget -> QWindow are not allowed)
in the end, I think you're better off forking BreezeWindowManager for QQuickItems, an use it only if not under kde4, possibly moving the widget move technology (wayland and stuff) to a common baseclass.
I am aware of this. Other option is to filter QEvent::Expose of QQuickWindows and then for contentItem of those windows filter QEvent::ChildAdded to find QQuickStyleItem.
Not sure what is better, the current solution appears to *work* even if there (probably?) is a case where isQtQuickItem would not pick the window.
big +1 on this.
to make it build on kde4, even if it's not pretty, could the method declarations be ifdeffed? implementations are mostly the same
Thanks for the updated patch !
I tested it compiles on kde4
Made a few suggestions above, then it can go.
| kstyle/breezewindowmanager.cpp | ||
|---|---|---|
| 467 | should be "return false" | |
| kstyle/breezewindowmanager.h | ||
| 176 | I'd rather use typedef, or even better "using Window = QWindow;" instead of preprocessors | |
| kstyle/breezewindowmanager.cpp | ||
|---|---|---|
| 467 | It needs to be return true. If we return false here, then we won't get following move and release events. We can eat events for QQuickItems, because we only get events that were not handled by any Item. | |
| kstyle/breezewindowmanager.cpp | ||
|---|---|---|
| 467 | Guess I'll trust you on that, though I am a bit surprised. | |
This patch has a disavantage (i'm not pretty sure it's this or Martin's) drag from empty area is ignored every even time e.g.
and so on...
Did you actually try to revert it and see if anything changes?
The problem is reproducible only with Qt 5.8, and it doesn't just block second drag - it breaks all mouse events until you click in the window to "reset" it. Because the wm move is started in between mouse click sequence (right after mouse press), Breeze is sending fake mouse release right after the wm move is started to make it look as normal mouse press + release to Qt. Unfortunately, this trick no longer works with Qt 5.8 and I have no idea how to fix it.
This would probably help us https://codereview.qt-project.org/#/c/150399/
Ah, the bug stays over an year opened. Ok i will investigate to re-simulate move start.
Did you actually try to revert it and see if anything changes?
The problem is reproducible only with Qt 5.8, and it doesn't just block second drag - it breaks all mouse events until you click in the window to "reset" it. Because the wm move is started in between mouse click sequence (right after mouse press), Breeze is sending fake mouse release right after the wm move is started to make it look as normal mouse press + release to Qt. Unfortunately, this trick no longer works with Qt 5.8 and I have no idea how to fix it.
This would probably help us https://codereview.qt-project.org/#/c/150399/
To David: this happend both with QtQuickControls and QWidgets ?
i'll need to upgrade to Qt5.8 to investigate.
(indeed I cannot reproduce with Qt5.7 and QWidget at least)
Workaround cannot be made, Qt 5.8 counts internal messages e.g. MouseEventPress internal wants MouseEventRelease intenal, our message can't mess counting. Will be good when Qt bug is closed :)