| Summary: | PySolFC (And possibly other Tkinter and Tk programs), after moving window, put the menu at the original menu position. | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Shlomi Fish <shlomif> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Flags: | thomas.luebking:
ReviewRequest+
|
| Priority: | NOR | ||
| Version: | 4.9.95 (RC 1) | ||
| Target Milestone: | 4.10 | ||
| Platform: | Mageia RPMs | ||
| OS: | Linux | ||
| URL: | https://github.com/shlomif/PySolFC/tree/deal_ms_cards | ||
| Latest Commit: | http://commits.kde.org/kde-workspace/bc3ccaeda1a691730a6af95451598a81d42c74d7 | Version Fixed In: | 4.10 |
| Sentry Crash Report: | |||
|
Description
Shlomi Fish
2012-12-29 17:04:39 UTC
Does it happen if you suspend the compositor (Shift+Alt+F12)? That sounds like a Client problem to me as menus are in general not managed by the window manager. The fact that it works with LXDE (it's Openbox, isn't it?) does not indicate a bug on our side here. tk has always be funny about window types - i would not expect the menu to be anything, but for the moment i assume the client misses the configure update, because we spare those but for the very last one during composited moves. thus the question. Hi Thomas, thanks for the very fast reply. (In reply to comment #1) > Does it happen if you suspend the compositor (Shift+Alt+F12)? If I disable the compositor (using a different keystroke though) it works like a charm, similar to what happens in LXDE. Reenabling the desktop effects using the keystroke make the bug happen again. =( XMaxima does the same (I forgot it uses TK as well) *drumrolll* AND HERE IT IS The Reason for the mighty SYNTHETIC CONFIGURATION NOTIFICATION (probably, tm) Techbabble, @Shlomi: you don't need to understand that :) The menu is override redirect, grabs the entire server (sigh) and actualyl sets the netwm popup type hint ;-) It relies on the configure notification (instead of obtaining its position when it needs it) - i can even completely scratch it from So perfroming that after the XMoveWindow() call in leaveMoveResize() fixes it. Next, i wondered, why we do this junk at all - KDE/Qt does completely not require it and i thought we maybe could spare some ... so i scratched it from handleMoveResize alltogether - no change on XMaxima, kwrite, qupzilla .. so i tried gtk[3]-demo / MainWindow. Turns out that moving and popup positioning works fine w/o the notification (yeah!) .. unfortunately the window will no longer react on resizes and sync requests - what also kinda explains our XSYNC problems with those fellows. I'll now kill sth. innocent and then see whether we can actually streamline the configure notifications at least a bit (eg. they're certainly not needed for composited moves) Hi Thomas, (In reply to comment #6) > https://git.reviewboard.kde.org/r/108013/ Great! Thanks for the confirmation, the investigation and the proposed fix. Regards, -- Shlomi Fish Git commit 727146bc55367f9f195cd078ebc7e7ed673a9354 by Thomas Lübking. Committed on 29/12/2012 at 22:27. Pushed by luebking into branch 'KDE/4.10'. use synthetic configure notifies when needed the patch omit them while the user just moves around a window and adds one that got lost with the deferred XMoveResize patch, causing FIXED-IN: 4.10 REVIEW: 108013 M +12 -6 kwin/geometry.cpp http://commits.kde.org/kde-workspace/727146bc55367f9f195cd078ebc7e7ed673a9354 Git commit bc3ccaeda1a691730a6af95451598a81d42c74d7 by Thomas Lübking. Committed on 29/12/2012 at 22:27. Pushed by luebking into branch 'master'. use synthetic configure notifies when needed the patch omit them while the user just moves around a window and adds one that got lost with the deferred XMoveResize patch, causing FIXED-IN: 4.10 REVIEW: 108013 M +12 -6 kwin/geometry.cpp http://commits.kde.org/kde-workspace/bc3ccaeda1a691730a6af95451598a81d42c74d7 |