This reverts commit 15aa7d0 as the Qt::WindowStaysOnTopHint workaround is ineffective on Wayland and causes flickering (see #903 and bitcoin/bitcoin#33432).
Wayland’s window behavior is controlled by the compositor, not the client.
This reverts commit 15aa7d0 as the Qt::WindowStaysOnTopHint workaround is ineffective on Wayland and causes flickering (see #903 and bitcoin/bitcoin#33432).
Wayland’s window behavior is controlled by the compositor, not the client.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
See the guideline for information on the review process.
Type | Reviewers |
---|---|
Concept ACK | pablomartin4btc |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
406@@ -407,10 +407,6 @@ void bringToFront(QWidget* w)
407 {
408 if (w) {
409 if (QGuiApplication::platformName() == "wayland") {
410- auto flags = w->windowFlags();
411- w->setWindowFlags(flags|Qt::WindowStaysOnTopHint);
412- w->show();
413- w->setWindowFlags(flags);
@hebasto Thanks for letting me know. I managed to reproduce the artifacts/flicker with the original code on sway and labwc (wlroots-based compositors). In both cases, getting rid of the flags fixed the issue.
I’ve not tested this on KWin and Mutter yet, I plan on doing that later today. Hopefully we can come up with a solution that works everywhere.
406@@ -407,10 +407,6 @@ void bringToFront(QWidget* w)
407 {
408 if (w) {
409 if (QGuiApplication::platformName() == "wayland") {
410- auto flags = w->windowFlags();
411- w->setWindowFlags(flags|Qt::WindowStaysOnTopHint);
412- w->show();
413- w->setWindowFlags(flags);
414 w->show();
Is it necessary now to call w->show();
here?
Would it be more clear to simply revert https://github.com/bitcoin-core/gui/commit/15aa7d023688700a47997b92108de95f2d864f5a?
This reverts commit 15aa7d0 as the Qt::WindowStaysOnTopHint workaround
is ineffective on Wayland and causes flickering (see #903 and
bitcoin/bitcoin#33432).
Wayland's window behavior is controlled by the compositor, not the
client.
Signed-off-by: Diego Viola <diego.viola@gmail.com>
Concept ACK
If you can, please check how this behaves on #817.