Summary: | [frameworks] Window menu in the wrong place | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Unknown <null> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hein, mail |
Priority: | NOR | Flags: | mgraesslin:
ReviewRequest+
|
Version: | git master | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
URL: | https://git.reviewboard.kde.org/r/118159/ | ||
Latest Commit: | http://commits.kde.org/kwin/8543033d59c5bfb2ae034bf39fa5cf61a626d2ed | Version Fixed In: |
Description
Unknown
2014-05-14 15:21:33 UTC
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. 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 |