Hi, Petr.
Fix looks good.
25.01.2013 12:39, Petr Pchelko wrote:
Hello, AWT Team.
Sorry for this mess with updates, please review the updated fix for the issue:
http://bugs.sun.com/view_bug.do?bug_id=8005405
The new version is available at:
http://cr.openjdk.java.net/~pchelko/8005405/webrev.02/
As Sergey noticed there was a bug in the previous version: the getParent method
could return an owner of the window an coordinates would be computed
incorrectly. In the updated version this issue is solved and the code is
further simplified.
Thank you.
With best regards. Petr.
On Jan 24, 2013, at 7:35 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please, review an updated fix for:
http://bugs.sun.com/view_bug.do?bug_id=8005405
at
http://cr.openjdk.java.net/~pchelko/8005405/webrev.01/
Sergey suggested to simplify the loop which computes the component offset. I
simplified it and deleted the check that a peer is an instance of
LWComponentPeer because as I understand it is always true for a root component
in the hierarchy on the mac.
The updated fix is tested on toy apps and on netbeans.
With best regards, Petr.
On Jan 23, 2013, at 6:35 PM, Petr Pchelko wrote:
Hello, AWT team.
Please, review the fix for the issue
http://bugs.sun.com/view_bug.do?bug_id=8005405
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8005405/webrev.00/
2 problem existed:
1. Calculation of the dragOrigin and componentOffset relied on the
component.isLightweight() method, which considers all the AWT components
heavyweight on Mac, however we really wanted there to find the component which
has a real NSView or NSWindow under it. Replacing it with instanceof Window
solves the problem.
2. On the native level the dragOrigin and location of the dragEvent
were calculated without respect to the fact than Cocoa coordinate system is
flipped.
The fix is tested on toy apps with both AWT and Swing components. Also I have
run netbeans on the JDK with this fix and all drag images look good.
With best regards. Petr.
--
Best regards, Sergey.
