Bug 312346 - PySolFC (And possibly other Tkinter and Tk programs), after moving window, put the menu at the original menu position.
Summary: PySolFC (And possibly other Tkinter and Tk programs), after moving window, pu...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.9.95 (RC 1)
Platform: Mageia RPMs Linux
: NOR normal
Target Milestone: 4.10
Assignee: KWin default assignee
URL: https://github.com/shlomif/PySolFC/tr...
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-29 17:04 UTC by Shlomi Fish
Modified: 2013-01-07 14:38 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.10
Sentry Crash Report:
thomas.luebking: ReviewRequest+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Shlomi Fish 2012-12-29 17:04:39 UTC
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.
Comment 1 Thomas Lübking 2012-12-29 17:14:51 UTC
Does it happen if you suspend the compositor (Shift+Alt+F12)?
Comment 2 Martin Flöser 2012-12-29 17:41:06 UTC
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.
Comment 3 Thomas Lübking 2012-12-29 17:53:53 UTC
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.
Comment 4 Shlomi Fish 2012-12-29 19:14:43 UTC
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.
Comment 5 Thomas Lübking 2012-12-29 20:51:39 UTC
=(
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)
Comment 6 Thomas Lübking 2012-12-29 21:31:48 UTC
https://git.reviewboard.kde.org/r/108013/
Comment 7 Shlomi Fish 2012-12-30 06:17:08 UTC
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
Comment 8 Thomas Lübking 2013-01-02 18:00:21 UTC
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
Comment 9 Thomas Lübking 2013-01-02 18:06:52 UTC
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