Hello, Alexander. > according to the simplified way of finding the top-level, have you tried > this code with applets? > I'm not sure this will work there, applet's top level component is instance > of Window.
Actually, without this fix dnd does not work in the embedded case on the Mac as native level wants an instance of an AWTWindow as a native peer for the top-level component. These changes do not make any worse, it still does not work. As for Applets in the AppletViewer which are used for tests - they work completely fine. The CALayer-based embedded case do not seem possible to fix. The NSView embedded case did not work before the fix, does not work with it, however I will make it work with the next fix which is almost ready. With best regards. Petr. On Jan 28, 2013, at 8:51 PM, Alexander Zuev wrote: > Petr, > > according to the simplified way of finding the top-level, have you tried > this code with applets? > I'm not sure this will work there, applet's top level component is instance > of Window. > > With best regards, > Alexander Zuev > > On 1/28/13 17:18, Petr Pchelko wrote: >> Hello, Leonid, Alexander. >> >> Artem told me that I could ask you for the second review on this fix. Could >> you please have a look? >> >> For your convenience: >> http://bugs.sun.com/view_bug.do?bug_id=8005405 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/8005405/webrev.02/ >> >> Thank you. >> With best regards. Petr. >> >> On Jan 25, 2013, at 1:56 PM, Sergey Bylokhov wrote: >> >>> 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. >>> >> >
