Re: AWT Dev [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
Hi, Alexander. Probably all this stuff can be simplified? Can you try to change TrackingRect to TrackingArea with appropriate flags like NSTrackingEnabledDuringMouseDrag etc. 07.08.2012 15:17, Alexander Scherbatiy wrote: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ This is a regression after the fix 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In the case where a toolbar is created under a mouse and it is dragged over the initial window the mouse enter/exit events should not be generated for the components which are under the toolbar. The current fix is supposed to solve this regression and also to fix generation of mouse enter/exit events for all cases where a mouse is dragged from one window to another or a new window is created under a mouse (like it is implemented for toolbar). Let's see the following cases 1) Mouse is dragged from a window and back to the same window. The Mac OS X system generates a mouse exit event only the first time when a mouse is dragged from a window and does not generate mouse enter/exit events next times during one drag trace. 2) Mouse is dragged from one window to another. The Mac OS X system does not generate mouse enter/exit events for the second window. 3) Mouse is dragged from one window to another and released. In this case the Mac OS X system generates mouse enter event for the second window only after releasing the mouse. 4) Clicking on window creates a new window after that the new window is dragged (toolbar dragging). However the Java system generates mouse enter/exit events each time when a mouse is dragged over any window. To fix this the following methods are introduced: - Get topmost window under mouse - Synthesize mouse enter/exit events for all windows The dispatchMouseEvent method from the LWWindowPeer class is handled previous and next components and is able to generate mouse enter/exit events for them. However the the AWTView native class contains isMouseOver flag which value becomes inconsistent if we do not updated it. Because of this the fix generates the mouse enter/exit window events on the native side. Generating mouse enter/exit events always should be in order where mouse exit events are generated before the mouse enter events. The synthesizeMouseEnteredExitedEventsForAllWindows method tries to generate mouse enter/exit events for all windows during mouse drag or window creation/window bounds changing. However only those windows which isMouseOver flag is differ from the isTopMostWindowUnderMouse state are affected. This method also tries to generate both mouse enter and exit event for the same window but only one of them can be applicable because the isTopMostWindowUnderMouse state is not changed for these calls. So the window enter/exit events now are always generated from the native system and component enter/exit events are generated in the LWWindowPeer class. LWWindowPeer class now uses three links to components: current, last and topmostUnderMouse. All of them are necessary because in case when a mouse is dragged from one window to another the current component receives drag events and last and topmostUnderMouse links handle components mouse exit/enter events on the second window. Thanks, Alexandr. -- Best regards, Sergey.
AWT Dev [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression)
Hi Everyone, Please review the fix. When we translate calls from our swing menu components to awt peer we resets information about shortcut in the setLabel(). This happens because of ScreenMenuItem.setAccelerator() method call peers setLabel(..,..,..) directly and does not initialize ScreenMenuItem.shortcut property. But default implementation of ScreenMenuItem.setLabel() assumes that this field(shortcut) will be initialized. This works on jdk6 because it does not reset shortcut if null or empty shortcut is provided. As a solution we can use peers methods directly in both cases. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 Webrev can be found at: http://cr.openjdk.java.net/~serb/7186371/webrev.00 -- Best regards, Sergey.
Re: AWT Dev JAWT Breakage in OpenJDK 7/8
Il giorno mar, 07/08/2012 alle 17.18 +0400, Anthony Petrov ha scritto: I agree with Artem that pre-loading the jawt library unconditionally is a bad thing to do, because even tiny milliseconds matter. Besides, a fair amount of Java GUI applications simply don't require jawt, so this pre-loading looks unnecessary. I also agree with Omair and Mario on that old applications cannot be modified sometimes, and therefore, whilst it makes some sense to update the doc and suggest developers to System.loadLibrary(jawt) in their app, we should still make sure old applications work as expected. I've also read the discussion that took place on build-dev@ regarding this issue, and it seems to me that adding an RPATH entry to launchers is the right solution for this issue. We may want to also add a comment there and state that this entry is added specifically to address the jawt use case. Perhaps it makes sense to also add a comment somewhere in a jawt makefile to state that we rely on this RPATH entry in the launcher. This way we can ensure that even if the jawt library is moved around, the relevant RPATH entry gets updated accordingly as well. This sounds to me a pretty good solution, yes, Thanks for looking at this issue! Cheers, Mario
Re: AWT Dev [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
I noticed that, NSWindow's windowNumber is NSInteger, which is 32 bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a simple 32 bit int is probably not what you intended to do. Also, have you considered simply calling -[NSWindow setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then removing the calls that flip it on and off in -[AWTView mouseEntered:] and -[AWTView mouseExited]? This would also require a change in Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), which has a comment that states it only turns on mouse moved events if the window is currently under the mouse. I would think that AppKit should be more than happy to send you mouse-over/enter/exited events as long as you say you want them. Was this approach tried and didn't work for some reason? Regards, Mike Swingler Apple Inc. On Aug 7, 2012, at 4:33 AM, Sergey Bylokhov sergey.bylok...@oracle.com wrote: Hi, Alexander. Probably all this stuff can be simplified? Can you try to change TrackingRect to TrackingArea with appropriate flags like NSTrackingEnabledDuringMouseDrag etc. 07.08.2012 15:17, Alexander Scherbatiy wrote: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ This is a regression after the fix 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In the case where a toolbar is created under a mouse and it is dragged over the initial window the mouse enter/exit events should not be generated for the components which are under the toolbar. The current fix is supposed to solve this regression and also to fix generation of mouse enter/exit events for all cases where a mouse is dragged from one window to another or a new window is created under a mouse (like it is implemented for toolbar). Let's see the following cases 1) Mouse is dragged from a window and back to the same window. The Mac OS X system generates a mouse exit event only the first time when a mouse is dragged from a window and does not generate mouse enter/exit events next times during one drag trace. 2) Mouse is dragged from one window to another. The Mac OS X system does not generate mouse enter/exit events for the second window. 3) Mouse is dragged from one window to another and released. In this case the Mac OS X system generates mouse enter event for the second window only after releasing the mouse. 4) Clicking on window creates a new window after that the new window is dragged (toolbar dragging). However the Java system generates mouse enter/exit events each time when a mouse is dragged over any window. To fix this the following methods are introduced: - Get topmost window under mouse - Synthesize mouse enter/exit events for all windows The dispatchMouseEvent method from the LWWindowPeer class is handled previous and next components and is able to generate mouse enter/exit events for them. However the the AWTView native class contains isMouseOver flag which value becomes inconsistent if we do not updated it. Because of this the fix generates the mouse enter/exit window events on the native side. Generating mouse enter/exit events always should be in order where mouse exit events are generated before the mouse enter events. The synthesizeMouseEnteredExitedEventsForAllWindows method tries to generate mouse enter/exit events for all windows during mouse drag or window creation/window bounds changing. However only those windows which isMouseOver flag is differ from the isTopMostWindowUnderMouse state are affected. This method also tries to generate both mouse enter and exit event for the same window but only one of them can be applicable because the isTopMostWindowUnderMouse state is not changed for these calls. So the window enter/exit events now are always generated from the native system and component enter/exit events are generated in the LWWindowPeer class. LWWindowPeer class now uses three links to components: current, last and topmostUnderMouse. All of them are necessary because in case when a mouse is dragged from one window to another the current component receives drag events and last and topmostUnderMouse links handle components mouse exit/enter events on the second window. Thanks, Alexandr. -- Best regards, Sergey.
AWT Dev hg: jdk8/awt/corba: Added tag jdk8-b50 for changeset d20d9eb9f093
Changeset: 9b0f841ca9f7 Author:katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/9b0f841ca9f7 Added tag jdk8-b50 for changeset d20d9eb9f093 ! .hgtags
AWT Dev hg: jdk8/awt/langtools: Added tag jdk8-b50 for changeset b2d8a270f5f2
Changeset: c4cd4cab2220 Author:katleman Date: 2012-08-02 15:37 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/c4cd4cab2220 Added tag jdk8-b50 for changeset b2d8a270f5f2 ! .hgtags
AWT Dev hg: jdk8/awt/jaxp: Added tag jdk8-b50 for changeset 2791ec55f66b
Changeset: dc1ea77ed9d9 Author:katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/dc1ea77ed9d9 Added tag jdk8-b50 for changeset 2791ec55f66b ! .hgtags
AWT Dev hg: jdk8/awt/hotspot: 37 new changesets
Changeset: 54e66510c9cd Author:amurillo Date: 2012-07-13 14:16 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/54e66510c9cd 7184050: new hotspot build - hs24-b17 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8150fa46d2ed Author:jiangli Date: 2012-06-26 19:08 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8150fa46d2ed 7178145: Change constMethodOop::_exception_table to optionally inlined u2 table. Summary: Change constMethodOop::_exception_table to optionally inlined u2 table. Reviewed-by: bdelsart, coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java + agent/src/share/classes/sun/jvm/hotspot/oops/ExceptionTableElement.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.cpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f0b82641fb7e Author:bdelsart Date: 2012-07-02 04:19 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f0b82641fb7e Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: d68b1274b9ba Author:jiangli Date: 2012-07-05 18:47 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d68b1274b9ba 7180914: Compilation warning after: 7172967: Eliminate the constMethod's _method backpointer to the methodOop. Summary: Use read_pointer(J...) to access from 'constMethod' base in name_for_methodOop(), libjvm_db.c. Reviewed-by: kvn, coleenp ! src/os/solaris/dtrace/libjvm_db.c Changeset: 161ae369407d Author:jiangli Date: 2012-07-05 20:54 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/161ae369407d 7181632: nsk classLoad001_14 failure and CompileTheWorld crash after 7178145. Summary: Need to copy the inlined exception table to the new constMethodOop during method rewriting. Reviewed-by: coleenp, dholmes ! src/share/vm/oops/methodOop.cpp Changeset: e74da3c2b827 Author:jiangli Date: 2012-07-13 20:14 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e74da3c2b827 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 0bca41b2fa63 Author:jiangli Date: 2012-07-17 12:32 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/0bca41b2fa63 Merge Changeset: 922993931b3d Author:brutisso Date: 2012-07-11 22:47 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/922993931b3d 7178361: G1: Make sure that PrintGC and PrintGCDetails use the same timing for the GC pause Summary: Also reviewed by: vita...@gmail.com. Move the timing out of G1CollectorPolicy into the G1GCPhaseTimes class Reviewed-by: johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 3a431b605145 Author:jmasa Date: 2012-07-16 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3a431b605145 Merge ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 7553d441b878 Author:jmasa Date: 2012-07-17
