anthonyfieroni added a comment.
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 :)
REPOSITORY
R31 Breeze
REVISION DETAIL
drosca added a comment.
@hpereiradacosta Yes, happens with both QQC and QWidgets.
REPOSITORY
R31 Breeze
REVISION DETAIL
https://phabricator.kde.org/D3578
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: drosca, #plasma, hpereiradacosta
Cc:
hpereiradacosta added a comment.
> 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
anthonyfieroni added a comment.
Ah, the bug stays over an year opened. Ok i will investigate to re-simulate
move start.
REPOSITORY
R31 Breeze
REVISION DETAIL
https://phabricator.kde.org/D3578
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: drosca,
drosca added a comment.
In https://phabricator.kde.org/D3578#83620, @anthonyfieroni wrote:
> 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.
Did you actually try to revert it and see if anything
anthonyfieroni added a comment.
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.
1. drag from empty area -> OK
2. drag again -> ignored
3. drag again -> OK
4. drag agina -> ignored
and so on...
hpereiradacosta added inline comments.
INLINE COMMENTS
> drosca wrote in 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
drosca added inline comments.
INLINE COMMENTS
> hpereiradacosta wrote in breezewindowmanager.cpp:467
> should be "return false"
> Comments few lines below says we never eat events.
It needs to be `return true`. If we return false here, then we won't get
following move and release events. We
hpereiradacosta added a comment.
Thanks for the updated patch !
I tested it compiles on kde4
Made a few suggestions above, then it can go.
INLINE COMMENTS
> breezewindowmanager.cpp:467
> +
> +return true;
> +}
should be "return false"
Comments few lines below says
mart added a comment.
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
REPOSITORY
R31 Breeze
REVISION DETAIL
https://phabricator.kde.org/D3578
EMAIL PREFERENCES
drosca added a comment.
In https://phabricator.kde.org/D3578#66969, @hpereiradacosta wrote:
> - Also note that you have no guarantee that all QtQuickItems pass through
IsQtQuick
> - This guy is called only in cases when you need slightly different render
path between widgets and
hpereiradacosta added a comment.
- Also note that you have no guarantee that all QtQuickItems pass through
IsQtQuick
- This guy is called only in cases when you need slightly different render
path between widgets and quick. Everywhere else, quicks are not checked and
thus cannot be
graesslin added a comment.
apart from being hacky: very nice! I would not have thought that this is
possible at all.
REPOSITORY
R31 Breeze
REVISION DETAIL
https://phabricator.kde.org/D3578
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: drosca,
13 matches
Mail list logo
