<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 12, 2017 at 4:02 PM, Martin Flöser <span dir="ltr"><<a href="mailto:mgraesslin@kde.org" target="_blank">mgraesslin@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
I had a look at the issues of KRunner on Wayland with Qt 5.9 and want to share my findings.<br>
<br>
What we see is KRunner working fine on first invokation, but afterwards everything is messed up:<br>
* maximized windows shortly change their size<br>
* KRunner opens behind other windows<br>
<br>
With WAYLAND_DEBUG I was able to understand the issue. On first invokation everything is normal:<br>
* Plasma shell surface gets created<br>
* Plasma shell surface gets positioned<br>
* Plasma shell surface gets marked as panel<br>
* Panel is set to windows go below<br>
* Panel is marked as accepts focus<br>
* Surface gets mapped<br>
<br>
Yay, a situation KWin can handle.<br>
<br>
Now the window gets hidden, and shown again and Qt recreates the surface. Due to queuing we have<br>
1. Surface gets mapped<br>
2. KWin shows the window at random position<br>
3. Plasma shell surface gets created and marked as panel<br>
4. KWin adjust it to be a panel and moves maximized windows around<br>
5. Plasma shell surface gets marked as panel with windows go below<br>
6. KWin adjust it to be a panel with windows go below and moves maximized windows around<br>
7. Panel gets marked as accepts focus (too late, too late)<br>
8. KRunner gets positioned<br>
<br>
So we are in a bad state. When looking at it our Plasma Shell Surface protocol is not double buffered which explains why KWin reacts on each and every of the actions. It was designed so that double buffered is not needed as it was supposed to be used before mapping the window.<br>
<br></blockquote>>
Any ideas or advice?<br><br></div><div class="gmail_quote">I can do inane rambling instead.<br><br>----<br><br></div><div class="gmail_quote">With Xdgv6 (in theory!) this ends up being a non-issue.<br><br></div><div class="gmail_quote">A client is not allowed to attach a buffer until it gets a configure event from the server. <br></div><div class="gmail_quote"><br>This throws in an extra roundtrip and according to my logs on the second showing that means we do get all the plasma shell stuff sent before we send a configure which means we'll have processed them all before we get the first buffer and map the window.<br></div><div class="gmail_quote"></div><div class="gmail_quote"><br></div><div class="gmail_quote">In practice we get the role and location, but not the position (which means I think I now get what Marco's wayland krunner was trying to do.)<br></div><div class="gmail_quote"><br>---<br><br></div><div class="gmail_quote">We should be double buffering the proper shells (wl_shell, xdgV5/6) and only emitting the surfaceCreated signals when the surface is comitted.<br><br></div><div class="gmail_quote">In practice that won't acheive anything as QWaylandWindow::initWindow calls commit a few times randomly before the expose event that we're currently hooking into is called. Also kwayland-integration calls commit on the surface every time it attaches something, which I don't think is right.<br></div><br><div>--<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Now with Qt's new behavior that bites our ass and I'm a little bit lost what to do. I think we can improve the situation by first setting the panel behavior, but the wrong position is something we cannot prevent if the window is already mapped. Even changing the protocol to be double buffered would not really help here as we are too late. It's not every frame is perfect.</blockquote><br></div><div>I do think we can change Qt's behaviour. With XdgV7 it's clarified that there really is no need to delete the xdg_toplevel to unmap.<br></div><div><br>That still leaves Qt having the "new behaviour" if one calls QWindow::setParent or QWindow::setType, but from our POV that's fine.<br><br></div><div>David<br></div><br></div></div>