Bug 334768

window menu (alt+f3) or appmenu (file/edit/...)?

> window menu (alt+f3) or appmenu (file/edit/...)?

window menu - we talked on IRC and I can reproduce.

relevant code in libkdecoration:

void KCommonDecoration::doShowWindowMenu()
{
    QRect menuRect = d->button[MenuButton]->rect();
    QPoint menutop = d->button[MenuButton]->mapToGlobal(menuRect.topLeft());
    QPoint menubottom = d->button[MenuButton]->mapToGlobal(menuRect.bottomRight()) + QPoint(0, 2);
    showWindowMenu(QRect(menutop, menubottom));
}

-> looks like the decoration widget doesn't get informed that it got moved.

seems to be related to any configure_window call. Other way to reproduce:

1. open menu
2. send to other screen
3. open menu

Either we suck away configure events from Qt in events.cpp or mapToGlobal() is broken (QWindow related?!)

interesting finding: I cannot reproduce for QWindow based decorations, only for QWidget based.

gutshot:
http://quickgit.kde.org/?p=kwin.git&a=commit&h=8ecb69cd8c956e46a06c1808d38706b07a3f3a24

On Thursday 15 May 2014 08:46:10 you wrote:
> https://bugs.kde.org/show_bug.cgi?id=334768
> 
> --- Comment #7 from Thomas Lübking <thomas.luebking@gmail.com> ---
> gutshot:
> http://quickgit.kde.org/?p=kwin.git&a=commit&h=8ecb69cd8c956e46a06c1808d3870
> 6b07a3f3a24

unlikely it just changes how we access the window id. As QWidget uses a 
QWindow internally, it's no change (yes I read the Qt code before changing 
that ;-) )

> interesting finding: I cannot reproduce for QWindow based decorations, only
> for QWidget based.

might be a false trail: Aurorae uses QCursor::pos() for passing the position 
to open the menu.

I have a fix, but I'm not sure whether I like it:

diff --git a/client.cpp b/client.cpp
index 1d25660..6d60cec 100644
--- a/client.cpp
+++ b/client.cpp
@@ -558,7 +558,7 @@ void Client::createDecoration(const QRect& oldgeom)
     } else if (decoration->window()) {
         decoration->window()->installEventFilter(this);
     }
-    xcb_reparent_window(connection(), decoration->window()->winId(), frameId(), 0, 0);
+    decoration->window()->setParent(QWindow::fromWinId(frameId()));
     decoration->window()->lower();
     decoration->borders(border_left, border_right, border_top, border_bottom);
     padding_left = padding_right = padding_top = padding_bottom = 0;

*** Bug 334882 has been marked as a duplicate of this bug. ***

well no surprise that Qt doesn't notice that the decoration window got reparented:

    case XCB_REPARENT_NOTIFY: {
        //do not confuse Qt with these events. After all, _we_ are the
        //window manager who does the reparenting.
        return true;
    }

but changing to false also doesn't fix it.

the issue is the move, not the reparenting. XCB_MOTION_NOTIFY looks more promising.
Could be due to tabbox grab bug or the altered logics.

forget what i said - it's hot.

*** Bug 335720 has been marked as a duplicate of this bug. ***

Git commit 8543033d59c5bfb2ae034bf39fa5cf61a626d2ed by Martin Gräßlin.
Committed on 16/05/2014 at 06:12.
Pushed by graesslin into branch 'master'.

Reparent decoration window by using a QWindow wrapper for the frame

Qt doesn't like that we reparent the decoration using low level xcb
calls. So let's use a QWindow wrapper for the frame and let Qt do
the reparenting itself.
REVIEW: 118159

M  +1    -1    client.cpp
M  +2    -0    client.h
M  +1    -0    manage.cpp

http://commits.kde.org/kwin/8543033d59c5bfb2ae034bf39fa5cf61a626d2ed