Hi all, I'm using kdebase4-workspace-4.9.90-1.mga3 on Mageia Linux 3/Cauldron with desktop effects on a Core i3 machine. When I run PySolFC from the branch in the URL it pops the window in a certain place. If immediately after that I move it and then invoke the File menu (by pressing on the label), then it causes the menu to appear in the PySolFC window's original location on the screen. Reproducible: Always Steps to Reproduce: 1. git clone https://github.com/shlomif/PySolFC.git 2. git checkout deal_ms_cards 3. python pysol.py 4. Move the main window with the card to the other corner of the screen 5. Press the "File" menu (or press Alt+F) Actual Results: The menu pops up at the original location of the window. Expected Results: It should pop up at the current location of the window. IT does not happen in LXDE on the same system.
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)
https://git.reviewboard.kde.org/r/108013/
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