AWT Dev hg: jdk7/awt/jdk: 6983562: Two java/awt tests failing just on jdk7b108
Changeset: 4eeff1fda9ea Author:serb Date: 2011-04-15 16:51 +0400 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/4eeff1fda9ea 6983562: Two java/awt tests failing just on jdk7b108 Reviewed-by: art, denis, dcherepanov ! src/windows/native/sun/windows/awt_Button.cpp ! src/windows/native/sun/windows/awt_Checkbox.cpp
AWT Dev hg: jdk7/awt/jdk: 7045193: interactive JCK tests java_awt/interactive/FileDialogTests fail
Changeset: f05164caa490 Author:serb Date: 2011-05-30 17:16 +0400 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/f05164caa490 7045193: interactive JCK tests java_awt/interactive/FileDialogTests fail Reviewed-by: dcherepanov, dav, art, denis ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java
AWT Dev hg: jdk8/awt/jdk: 5 new changesets
Changeset: 6ee24f03760d Author:serb Date: 2011-07-15 19:18 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6ee24f03760d 7043679: Wrong class name is used in Java_sun_awt_windows_WPrinterJob_initIDs Reviewed-by: dav, art ! src/windows/native/sun/windows/awt_PrintJob.cpp Changeset: c90a43ebf8fd Author:serb Date: 2011-07-15 19:19 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c90a43ebf8fd 7043815: AWT-XAWT - AWT-EventQueue-0 deadlock. Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java Changeset: 252f71b26b23 Author:serb Date: 2011-07-15 19:23 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/252f71b26b23 6596915: JCK-runtime-6a/tests/api/java_awt/Component/index.html tesPaintAll fails Reviewed-by: art, dcherepanov, anthony ! src/solaris/classes/sun/awt/X11/XButtonPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XLabelPeer.java ! src/solaris/classes/sun/awt/X11/XListPeer.java ! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java ! src/solaris/classes/sun/awt/X11/XMenuWindow.java ! src/solaris/classes/sun/awt/X11/XPanelPeer.java ! src/solaris/classes/sun/awt/X11/XRepaintArea.java ! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java ! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java ! src/solaris/classes/sun/awt/X11/XWarningWindow.java ! src/solaris/classes/sun/awt/X11/XWindow.java + test/java/awt/Component/PaintAll/PaintAll.java Changeset: 3ed58dbad819 Author:serb Date: 2011-07-15 19:24 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3ed58dbad819 6642728: Use reflection to access ScrollPane's private method from within sun.awt package Reviewed-by: art, anthony ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java ! src/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/windows/native/sun/windows/awt_ScrollPane.cpp Changeset: 9c642ae9a543 Author:serb Date: 2011-07-15 19:25 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9c642ae9a543 4717864: setFont() does not update Fonts of Menus already on screen Reviewed-by: art, bagiras ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/native/sun/windows/awt_Menu.cpp ! src/windows/native/sun/windows/awt_Menu.h ! src/windows/native/sun/windows/awt_MenuBar.cpp ! src/windows/native/sun/windows/awt_MenuBar.h ! src/windows/native/sun/windows/awt_MenuItem.cpp ! src/windows/native/sun/windows/awt_MenuItem.h
Re: AWT Dev AWT group member proposal
Vote: YES 08.09.2011 20:02, Artem Ananiev wrote: Hi, awt-dev, according to the OpenJDK community Bylaws [1], as an AWT group member I hereby propose to add Oleg Pekhovskiy to the list of group users. Oleg is a member of AWT engineering group at Oracle and has already contributed a number of significant AWT fixes to OpenJDK. [1] http://openjdk.java.net/groups/gb/bylaws/draft-openjdk-bylaws-10#_5 Thanks Artem -- Best regards, Sergey.
AWT Dev hg: jdk8/awt/jdk: 6996291: command line selection of MToolkit by -Dawt.toolkit=sun.awt.motif.MToolkit fails from jdk7 b21 on
Changeset: 28f768c41a90 Author:serb Date: 2011-11-12 04:13 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/28f768c41a90 6996291: command line selection of MToolkit by -Dawt.toolkit=sun.awt.motif.MToolkit fails from jdk7 b21 on Reviewed-by: art, dcherepanov, bae, prr ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/awt/mawt.gmk - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/ListHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java - src/solaris/classes/sun/awt/motif/AWTLockAccess.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h ! src/solaris/native/sun/awt/awt.h ! src/solaris/native/sun/awt/awt_AWTEvent.c ! src/solaris/native/sun/awt/awt_Component.h - src/solaris/native/sun/awt/awt_Cursor.h ! src/solaris/native/sun/awt/awt_DrawingSurface.c ! src/solaris/native/sun/awt/awt_Font.c ! src/solaris/native/sun/awt/awt_Font.h ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_InputMethod.c - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h ! src/solaris/native/sun/awt/awt_Robot.c - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h ! src/solaris/native/sun/awt/awt_p.h ! src/solaris/native/sun/awt/awt_util.c ! src/solaris/native/sun/awt/awt_util.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h ! src/solaris/native/sun/awt/canvas.h ! src/solaris/native/sun/awt/multi_font.c ! src/solaris/native/sun/awt/multi_font.h ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.h ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/xawt/XToolkit.c
AWT Dev hg: jdk8/awt/jdk: 7115400: jdk 8 awt-gate build fails in headless toolkit on solaris.
Changeset: 79b5c5a8c7e9 Author:serb Date: 2011-12-05 17:11 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/79b5c5a8c7e9 7115400: jdk 8 awt-gate build fails in headless toolkit on solaris. Reviewed-by: prr, art, bae ! make/sun/awt/FILES_c_unix.gmk + src/solaris/native/sun/awt/HeadlessToolkit.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.h
Re: AWT Dev Review request for 7124553: [macosx] Need minimum size for titled Frames and JFrames
Hi, Anthony. What happens if small decorated nonresizable window became resizable(growbox will be shown). As far I understand window should increase its size? Correct? 15.02.2012 17:15, Anthony Petrov wrote: Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124553 at: http://cr.openjdk.java.net/~anthony/x-15-frameMinSize-7124553.0/ With this fix we constrain the size used for setBounds() and setMinMaxSize() operations so that it always includes the size of window decorations and the grow box when they're enabled. The size of (1, 1) is considered as the smallest possible size for a window in any case. -- best regards, Anthony -- Best regards, Sergey.
Re: AWT Dev [7u4] Review request for 7154177: [macosx] An invisible owner frame becomes visible upon clicking a child window
Hi Anthony. probably it would be good to add 2 regression tests for this issue? 1) For the current issue, which wasn't found by the existing tests. 2) For the issue which was not resolved in the current fix. 16.03.2012 19:22, Anthony Petrov wrote: Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7154177 at: http://cr.openjdk.java.net/~anthony/7u4-5-invisibleOwner-7154177.0/ Basically, with this fix we make sure we never make an invisible window an owner or a child for another window on the native level. This way the OS won't accidentally show an invisible window on the screen. Note that there's one scenario that isn't handled properly with this fix: // visible root owner // invisible owner // visible dialog In this case the visible dialog will not be tied with the visible root owner by the child-parent relationship. However, this scenario seems to be very unlikely to occur in real life. -- best regards, Anthony -- Best regards, Sergey.
Re: AWT Dev [7u4] Review request for 7154177: [macosx] An invisible owner frame becomes visible upon clicking a child window
Hi, Anthony. looks good. 20.03.2012 16:07, Anthony Petrov wrote: Hi Sergey, Thanks for the review. Indeed, a test case should be fine for this fix, so here's the updated webrev: http://cr.openjdk.java.net/~anthony/7u4-5-invisibleOwner-7154177.1/ As to the 2), I prefer to not add tests for things that should be improved eventually, so instead I've filed a CR 7155164 to address this issue later. -- best regards, Anthony On 3/19/2012 4:23 PM, Sergey Bylokhov wrote: Hi Anthony. probably it would be good to add 2 regression tests for this issue? 1) For the current issue, which wasn't found by the existing tests. 2) For the issue which was not resolved in the current fix. 16.03.2012 19:22, Anthony Petrov wrote: Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7154177 at: http://cr.openjdk.java.net/~anthony/7u4-5-invisibleOwner-7154177.0/ Basically, with this fix we make sure we never make an invisible window an owner or a child for another window on the native level. This way the OS won't accidentally show an invisible window on the screen. Note that there's one scenario that isn't handled properly with this fix: // visible root owner // invisible owner // visible dialog In this case the visible dialog will not be tied with the visible root owner by the child-parent relationship. However, this scenario seems to be very unlikely to occur in real life. -- best regards, Anthony -- Best regards, Sergey.
AWT Dev [8] Request for review: 7149913 [macosx] Deadlock in LWTextComponentPeer
Hi Everyone, This is a forward port from jdk 7u4: http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/91ede930328c Deadlock happens when 2 threads lock delegateLock and DefaultCaret object in different order. Removed code initially was added to stop recursion between paintPeer and addDirtyRegion( repaintPeer()-paintPeer()-print()-addDirtyRegion()-repaintPeer()- etc), but it is impossible now because repaintPeer() asynchronous. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 Webrev can be found at: http://cr.openjdk.java.net/~serb/7149913/webrev.00/ -- Best regards, Sergey.
AWT Dev [8] Request for approval: 7124528 [macosx] Selection is not cleared properly in text component.
Hi Everyone, This is a forward port from jdk 7u4: hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/7816a64158c4 Now we reset selection in text components on focuslost event. Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124528 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124528/webrev.01 http://cr.openjdk.java.net/%7Eserb/7124528/webrev.00/ -- Best regards, Sergey.
Re: AWT Dev [8] Request for review: 7149913 [macosx] Deadlock in LWTextComponentPeer
Hi, Artem. AWT tree lock used for locking delegate. 26.03.2012 17:37, Artem Ananiev wrote: Hi, Sergey, On 3/22/2012 6:05 PM, Sergey Bylokhov wrote: Hi Everyone, This is a forward port from jdk 7u4: http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/91ede930328c Deadlock happens when 2 threads lock delegateLock and DefaultCaret object in different order. Removed code initially was added to stop recursion between paintPeer and addDirtyRegion( repaintPeer()-paintPeer()-print()-addDirtyRegion()-repaintPeer()- etc), but it is impossible now because repaintPeer() asynchronous. according to the stack trace in bug description, the evaluation above doesn't look right. Initially reported deadlock involved AWT tree lock, not delegate lock. Thanks, Artem Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 Webrev can be found at: http://cr.openjdk.java.net/~serb/7149913/webrev.00/ -- Best regards, Sergey.
AWT Dev [8] Request for review: 7097771 setEnabled does not work for components in disabled containers.
Hi Everyone, We should check container status before we set status of the component. This check was done during initialization before, it was moved to setEnabled() method. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7097771 Webrev can be found at: http://cr.openjdk.java.net/~serb/7097771/webrev.00/ -- Best regards, Sergey.
Re: AWT Dev [8] Request for review: 7149913 [macosx] Deadlock in LWTextComponentPeer
Hi Artem. Done. 26.03.2012 19:26, Artem Ananiev написал: On 3/26/2012 5:37 PM, Sergey Bylokhov wrote: Hi, Artem. AWT tree lock used for locking delegate. Ah, right, I was confused by the method name, getDelegateLock()... OK, could you add some information to the bug, please? Right now Evaluation contains a statement about the deadlock, but not about what it is caused by and how it can be resolved. Thanks, Artem 26.03.2012 17:37, Artem Ananiev wrote: Hi, Sergey, On 3/22/2012 6:05 PM, Sergey Bylokhov wrote: Hi Everyone, This is a forward port from jdk 7u4: http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/91ede930328c Deadlock happens when 2 threads lock delegateLock and DefaultCaret object in different order. Removed code initially was added to stop recursion between paintPeer and addDirtyRegion( repaintPeer()-paintPeer()-print()-addDirtyRegion()-repaintPeer()- etc), but it is impossible now because repaintPeer() asynchronous. according to the stack trace in bug description, the evaluation above doesn't look right. Initially reported deadlock involved AWT tree lock, not delegate lock. Thanks, Artem Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 Webrev can be found at: http://cr.openjdk.java.net/~serb/7149913/webrev.00/ -- Best regards, Sergey.
AWT Dev [8] Request for review: 7124551 [macosx] Once added, Menu shortcut cannot be removed
Hi Everyone, We should accept empty KeyEquivalent in case of shortcut removing. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124551 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124551/webrev.00/ -- Best regards, Sergey.
AWT Dev [8] Request for review: 7125657 [macosx] SpreadSheet demo has the broken display when clicking outside of the table
Hi Everyone, This is a forward port from jdk 7u4: http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/fab57f1dc2aa The general bug is that we repaint native part of the LWPanelPeer after UPDATE event. This is not mac specific bug, because we do the same things on XToolkit too. But this demo works there because XPanel.paintPeer is noop. Fox XToolkit new bug will be created. Note that testworks in MToolkit and WToolkit. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125657 Webrev can be found at: http://cr.openjdk.java.net/~serb/7125657/webrev.00/ -- Best regards, Sergey.
AWT Dev [8] Request for review: 7150100 [macosx] 0123456789 is selected in the TextField.
Hi Everyone, Two issues resolved: 1) We should set caret position before the text selection. 2) On macosx we clear selection when the test component lost its focus, so test was simplified and instructions dialog was removed (because sometimes it steal the focus from the text component) Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150100 ** Webrev can be found at: http://cr.openjdk.java.net/~serb/7150100/webrev.00/ -- Best regards, Sergey.
Re: AWT Dev [8] Request for review: 7150100 [macosx] 0123456789 is selected in the TextField.
Hi Mike. 28.03.2012 20:18, Mike Swingler wrote: Does this change the behavior of where the cursor ends up if you press the left or right keys while there is a selection? We get this wrong in Java SE 6, and I was wondering if this corrects that behavior. Regards, Mike Swingler Apple Inc. No. Initial selected text in TextArea/TextField was fixed only(now it works in the same way as in swing). Feel free to file some jdk6 issues in jdk7 database if applicable. -- Best regards, Sergey.
AWT Dev hg: jdk8/awt/jdk: 7124551: [macosx] Once added, Menu shortcut cannot be removed
Changeset: 74a1284ca75a Author:serb Date: 2012-03-29 17:31 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/74a1284ca75a 7124551: [macosx] Once added, Menu shortcut cannot be removed Reviewed-by: art, anthony ! src/macosx/native/sun/awt/CMenuItem.m
AWT Dev [7u6] Request for review: 7124551 [macosx] Once added, Menu shortcut cannot be removed
Hi Everyone, We should accept empty KeyEquivalent in case of shortcut removing. This is a back port from jdk 8: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/74a1284ca75a Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124551 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124551/webrev.00/ -- Best regards, Sergey.
AWT Dev [8] Request for review: 7124401 [macosx] After call Frame dispose() application continues to work
Hi Everyone, On the latest version the dispose works as expected, but the test expects that the window will be fully red. But it is not true on the mac because of resizegrowboxwindow. Testcase updated. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124401 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124401/webrev.00/ -- Best regards, Sergey.
AWT Dev [8] Request for review: 7080109 Dialog.show() lacks doPrivileged() to access system event queue
Hi Everyone, In the fix doPrivileged was added to Dialog.show(). Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7080109 Webrev can be found at: http://cr.openjdk.java.net/~serb/7080109/webrev.00/ -- Best regards, Sergey.
AWT Dev [8] Request for review: 7150105 [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor.
Hi Everyone, A subcomponents may want to override the cursor over some of their parts(LWTextAreaPeer changes the cursor over scrollbars). Changes description: 1. LWComponentPeer.java: - Just one method added getCursor(); 2. LWCursorManager.java: - updateCursorImpl now use LWComponentPeer.getCursor() if applicable. - cleanup + TODO implemented // TODO: it's possible to get the component under cursor directly as 3. LWTextAreaPeer.java: - Changes the cursor over scrollbars. 4. LWWindowPeer.java: - We should update cursor even on MOUSE_EXIT event. 5. CCursorManager.java: - currentCursor was always null. Unused method getNativeWindow() removed. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150105 Webrev can be found at: http://cr.openjdk.java.net/~serb/7150105/webrev.00/ -- Best regards, Sergey.
AWT Dev [8] Request for review: 7154025 [macosx] XAWTDifference case load nothing about the components in standframe except gray.
Hi Everyone, See comments from the bug description: /1. The image in Standard frame is not painted, until the frame is [manually] resized./ Fixed: Observer was added to the drawImage(). / 2. Test instructions should be corrected to have an explicit statement about components layout. Obviously, the motif image doesn't correspond to the test, it's just a set of motif widgets laid out randomly in the window. /Fixed: Image was updated./ /Old image: http://cr.openjdk.java.net/~serb/7154025/old/MotifColors.jpg New image: http://cr.openjdk.java.net/~serb/7154025/new/MotifColors.jpg / 3. Editable/non-editable TextField colors should differ. I'm not sure about this, though, we should first check how native Cocoa widgets behave. /This is correct behavior. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154025 Webrev can be found at: http://cr.openjdk.java.net/~serb/7154025/webrev.00/ Webrev against closed part: http://cr.openjdk.java.net/~serb/7154025/closed/webrev/ -- Best regards, Sergey.
AWT Dev [8] Request for review: 7124534 [macosx] Submenu title overlaps with Submenu indicator in JPopupMenu
Hi Everyone, This testcase was targeted to the bug in metal and motif lf. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124534 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124534/webrev.00/ Webrev against closed part: http://cr.openjdk.java.net/~serb/7124534/closed/webrev/ -- Best regards, Sergey.
AWT Dev hg: jdk8/awt/jdk: 7150105: [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor.
Changeset: 933ea89bec06 Author:serb Date: 2012-04-05 18:27 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/933ea89bec06 7150105: [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor. Reviewed-by: anthony, art, alexp ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWCursorManager.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java
AWT Dev hg: jdk8/awt/jdk: 7124401: [macosx] After call Frame dispose() application continues to work
Changeset: 14646df8f386 Author:serb Date: 2012-04-05 19:01 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/14646df8f386 7124401: [macosx] After call Frame dispose() application continues to work Reviewed-by: art, alexp ! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java
AWT Dev hg: jdk8/awt/jdk: 7124528: [macosx] Selection is not cleared properly in text component.
Changeset: 004d53e61c3b Author:serb Date: 2012-04-05 19:43 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/004d53e61c3b 7124528: [macosx] Selection is not cleared properly in text component. Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java
AWT Dev hg: jdk8/awt/jdk: 7125657: [macosx] SpreadSheet demo has the broken display when clicking outside of the table.
Changeset: dc0d4cf71dfb Author:serb Date: 2012-04-05 20:38 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/dc0d4cf71dfb 7125657: [macosx] SpreadSheet demo has the broken display when clicking outside of the table. Reviewed-by: alexp, anthony, art ! src/macosx/classes/sun/lwawt/LWRepaintArea.java
Re: AWT Dev [8] Request for review: 7150100 [macosx] 0123456789 is selected in the TextField.
05.04.2012 14:53, Artem Ananiev написал: Hi, Sergey, On 3/28/2012 8:05 PM, Sergey Bylokhov wrote: Hi Everyone, Two issues resolved: 1) We should set caret position before the text selection. it's not clear why this particular change fixes the selection. Could you add more comments to the bug evaluation, please? comment added: This happens because at the beginning of LWTextComponentPeer initialization we select text and then we call JTextComponent.setCaretPosition() which clears selection. Thanks, Artem 2) On macosx we clear selection when the test component lost its focus, so test was simplified and instructions dialog was removed (because sometimes it steal the focus from the text component) Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150100 ** Webrev can be found at: http://cr.openjdk.java.net/~serb/7150100/webrev.00/ -- Best regards, Sergey. -- Best regards, Sergey.
AWT Dev [8] Request for review: 7147055 [macosx] Cursors are changing over a blocked window; also blinking
Hi Everyone, Cursor for blocked window was fixed. Now we use default cursor in this case. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147055 Webrev can be found at: http://cr.openjdk.java.net/~serb/7147055/webrev.00 -- Best regards, Sergey.
AWT Dev hg: jdk8/awt/jdk: 7097771: setEnabled does not work for components in disabled containers.
Changeset: 33c604bf074f Author:serb Date: 2012-04-10 22:09 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/33c604bf074f 7097771: setEnabled does not work for components in disabled containers. Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XComponentPeer.java + test/java/awt/Component/7097771/bug7097771.java
AWT Dev [8] Request for review: 7160623 [macosx] Editable TextArea/TextField are blocking GUI applications from exit
Hi Everyone, This is a port of 7155298 to macosx. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160623 Webrev can be found at: http://cr.openjdk.java.net/~serb/7160623/webrev.00 Discussion about xawt fix: http://mail.openjdk.java.net/pipermail/awt-dev/2012-March/002381.html -- Best regards, Sergey.
Re: AWT Dev [8] Request for review: 7080109 Dialog.show() lacks doPrivileged() to access system event queue
Hi, Artem.
Thanks for view.
Scope was changed. Here is an updated version:
http://cr.openjdk.java.net/~serb/7080109/webrev.01/
05.04.2012 14:46, Artem Ananiev wrote:
Hi, Sergey,
to limit the scope of the added doPrivileged() block, I would rewrite
the code this way:
secondaryLoop = AccessController.doPrivileged(
new PrivilegedActionSecondaryLoop() {
public SecondaryLoop run() {
EventQueue eventQueue =
Toolkit.getDefaultToolkit().getSystemEventQueue();
return eventQueue.createSecondaryLoop(
cond, modalFilter, 0);
}
}
);
if (!secondaryLoop.enter()) {
secondaryLoop = null;
}
Thanks,
Artem
On 3/30/2012 8:22 PM, Sergey Bylokhov wrote:
Hi Everyone,
In the fix doPrivileged was added to Dialog.show().
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7080109
Webrev can be found at:
http://cr.openjdk.java.net/~serb/7080109/webrev.00/
--
Best regards, Sergey.
Re: AWT Dev [8] Request for review for 7161109: [macosx] JCK AWT interactive test DnDTextDropTest fails on MacOS
Hi, Alexander. Fix looks good. 16.04.2012 22:12, Alexander Zuev wrote Hello, please review my fix for CR 7161109: [macosx] JCK AWT interactive test DnDTextDropTest fails on MacOS The fix is just a forward-port of fix for CR 7124262 which was not synced up into jdk8 workspace. Bug description: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161109 Webrev: http://cr.openjdk.java.net/~kizune/7161109/webrev.00 Withe best regards, Alexander Zuev -- Best regards, Sergey.
Re: AWT Dev [8] Request for review: 7124213: [macosx] pack() does ignore size of a component; doesn't on the other platforms.
Hi, Artem. Yes LWTextAreaPeer uses the same approach(60,10). But in the fix I change LWScrollPanePeer. Hi, Sergey, I'm fine with the fix, just curious about ... should work in the same way as on other platforms. Both on Windows and X11 TextArea peer's minimum size is calculated as the size of TextArea that consists of 10 rows by 60 columns. What did you mean then? Thanks, On 4/16/2012 6:50 PM, Sergey Bylokhov wrote: Hi Everyone, LWScrollPanePeer.getMinimumSize() on macosx should work in the same way, as on other platforms. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124213 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124213/webrev.00/
AWT Dev Objective-C and jcheck
Hi Everybody. Looks like on the server we still use jcheck without fix for Objective-C files? Does anybody know how to apply the fix to jdk8? (see attachment) [jdk] pulling from http://hg.openjdk.java.net/jdk8/awt/jdk searching for changes adding changesets adding manifests adding file changes added 1 changesets with 10 changes to 10 files [jcheck 25e85a608db1 2011-07-08 09:19 -0700] Changeset: 5305:0fad89bd606b Author:alexsch Date: 2012-05-02 17:54 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side Reviewed-by: anthony, leonidr src/macosx/native/sun/awt/AWTView.m:84: Trailing whitespace src/macosx/native/sun/awt/AWTWindow.m:173: Trailing whitespace transaction abort! rollback completed skipped: pretxnchangegroup.jcheck hook failed 02.05.2012 17:53, alexandr.scherba...@oracle.com wrote Changeset: 0fad89bd606b Author:alexsch Date: 2012-05-02 17:54 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0fad89bd606b 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side Reviewed-by: anthony, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTView.h ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java + test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java + test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java ! test/java/awt/regtesthelpers/Util.java ---BeginMessage--- Folks, The 'official' copy of jcheck is not scanning .m or .mm files for whitespace violations. I use a local copy of the latest jcheck so I don't have to be on VPN all the time, and I modified the script to look at .m files as well. Two change sets just arrived with trailing whitespace. From what I have been told about mercurial and the way jcheck works, fixing this is going to be more than a simple script change because jcheck looks at each changeset as they are applied to your local workspace. I think I can work around this by relaxing the pretxnchangegroup.jcheck but we really should investigate this soon. The jcheck script fix is very easy. Change line 142 to: normext_re = re.compile(.*\.(java|c|h|cpp|hpp|m|mm)$) -- Scott K. Scott Kovatch scott.kova...@oracle.com Santa Clara/Pleasanton, CA ---End Message---
Re: AWT Dev [8] Request for review: 7147055 [macosx] Cursors are changing over a blocked window; also blinking
Hi Everyone. Does anybody has a chance to review the fix? One more reviewer needed. Thanks. 09.04.2012 19:57, Sergey Bylokhov wrote: Hi Everyone, Cursor for blocked window was fixed. Now we use default cursor in this case. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147055 Webrev can be found at: http://cr.openjdk.java.net/~serb/7147055/webrev.00 -- Best regards, Sergey.
Re: AWT Dev [8] Request for review: 7080109 Dialog.show() lacks doPrivileged() to access system event queue
Hi Everyone.
Artem thanks for review. Does anybody has a chance to review the fix?
One more reviewer needed.
Thanks.
16.04.2012 21:00, Sergey Bylokhov wrote:
Hi, Artem.
Thanks for view.
Scope was changed. Here is an updated version:
http://cr.openjdk.java.net/~serb/7080109/webrev.01/
05.04.2012 14:46, Artem Ananiev wrote:
Hi, Sergey,
to limit the scope of the added doPrivileged() block, I would rewrite
the code this way:
secondaryLoop = AccessController.doPrivileged(
new PrivilegedActionSecondaryLoop() {
public SecondaryLoop run() {
EventQueue eventQueue =
Toolkit.getDefaultToolkit().getSystemEventQueue();
return eventQueue.createSecondaryLoop(
cond, modalFilter, 0);
}
}
);
if (!secondaryLoop.enter()) {
secondaryLoop = null;
}
Thanks,
Artem
On 3/30/2012 8:22 PM, Sergey Bylokhov wrote:
Hi Everyone,
In the fix doPrivileged was added to Dialog.show().
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7080109
Webrev can be found at:
http://cr.openjdk.java.net/~serb/7080109/webrev.00/
AWT Dev hg: jdk8/awt/jdk: 7147055: [macosx] Cursors are changing over a blocked window; also blinking
Changeset: 0feee4541f67 Author:serb Date: 2012-05-04 21:25 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0feee4541f67 7147055: [macosx] Cursors are changing over a blocked window; also blinking Reviewed-by: art, kizune ! src/macosx/classes/sun/lwawt/LWCursorManager.java
Re: AWT Dev hg: jdk8/awt/jdk: 7024963: Notepad demo: remove non-translatable resources from Notepad.properties file
Hi, Alexandr.
In this fix fileDialog variable was deleted from the Notepad.java. But
it is used in Stylepad demo. So now full jdk build failed with error:
C:\moe\workspaces\jdk\8\awt-mix\build\windows-i586\democlasses\demo\jfc\Stylepad\src\Stylepad.java:249:
error: cannot find symbol
if (fileDialog == null) {
^
symbol: variable fileDialog
location: class Stylepad.OpenAction
04.05.2012 13:16, alexandr.scherba...@oracle.com wrote:
Changeset: a714e2e2b257
Author:alexsch
Date: 2012-05-04 13:15 +0400
URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a714e2e2b257
7024963: Notepad demo: remove non-translatable resources from
Notepad.properties file
Reviewed-by: rupashka
! src/share/demo/jfc/Notepad/Notepad.java
! src/share/demo/jfc/Notepad/resources/Notepad.properties
+ src/share/demo/jfc/Notepad/resources/system.properties
AWT Dev hg: jdk8/awt/jdk: 7080109: Dialog.show() lacks doPrivileged() to access system event queue
Changeset: 912e666b4e1d Author:serb Date: 2012-05-10 20:05 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/912e666b4e1d 7080109: Dialog.show() lacks doPrivileged() to access system event queue Reviewed-by: art, anthony ! src/share/classes/java/awt/Dialog.java + test/java/awt/Dialog/ModalDialogPermission/ModalDialogPermission.java + test/java/awt/Dialog/ModalDialogPermission/java.policy
Re: AWT Dev [7u6] Review request for 7166437: [macosx] Support for Window.Type.UTILITY on the Mac
Hi, Anthony. Fix looks good. 11.05.2012 19:55, Anthony Petrov wrote: Hello, This is a backport of exactly the same fix from JDK 8. Bug: http://bugs.sun.com/view_bug.do?bug_id=7166437 Fix: http://cr.openjdk.java.net/~anthony/7u6-8-UTILITY-7166437.0/ -- best regards, Anthony
AWT Dev [7u6] Request for review: 7080109 Dialog.show() lacks doPrivileged() to access system event queue
Hi Everyone, This is a back port from jdk 8 to jdk 7u6. In the fix doPrivileged was added to Dialog.show(). Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7080109 Webrev can be found at: http://cr.openjdk.java.net/~serb/7080109/webrev.01 jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/912e666b4e1d -- Best regards, Sergey.
AWT Dev [7u6] Request for review: 7080109 Dialog.show() lacks doPrivileged() to access system event queue
Hi Everyone, This is a back port from jdk 8 to jdk 7u6. In the fix doPrivileged was added to Dialog.show(). Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7080109 Webrev can be found at: http://cr.openjdk.java.net/~serb/7080109/webrev.01 jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/912e666b4e1d -- Best regards, Sergey.
Re: AWT Dev [7u6] Request for review: 7160623 [macosx] Editable TextArea/TextField are blocking GUI applications from exit
Thanks, Anthony. Does anybody has a chance to review the fix? One more reviewer needed. 04.05.2012 16:09, Anthony Petrov wrote: The fix still looks fine. -- best regards, Anthony On 5/3/2012 7:16 PM, Sergey Bylokhov wrote: Hi Everyone, This is a back port from jdk 8 to jdk 7u6. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160623 jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c31eeeda3ed1 Webrev can be found at: http://cr.openjdk.java.net/~serb/7160623/webrev.00 Discussion about the same xawt fix: http://mail.openjdk.java.net/pipermail/awt-dev/2012-March/002381.html -- Best regards, Sergey.
Re: AWT Dev Request for Review: 7170655 frame size change does not follow label font change
Hi, Jonathan, Fix looks good. But I guess this bug was not caught by the regression tests, so new test should be added(automatic test is better). 23.05.2012 14:15, Jonathan Lu wrote: Hi Sergey, On 05/22/2012 10:23 PM, Sergey Bylokhov wrote: Hi, Jonathan, Looks like this bug is duplicate of http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161865 And the reason of the issue is that we post UpdateEvent in target.repaint() in XLabelPeer.setFont(), but we should paint native part of the component in place[1] and then post PaintEvent[2]. - To fix [1] we can replace target.repaint() to repaint() in setFont(). Does it solve your issue? Yes, this resolves my problem, and here's the updated patch from your suggestion, http://cr.openjdk.java.net/~luchsh/7170655_2/ Thanks a lot! - Jonathan 22.05.2012 11:47, Jonathan Lu wrote: Hi awt-dev, Here's a patch for bug 7170655, could anybody please help to take a look? http://cr.openjdk.java.net/~luchsh/7170655/ The problem is that painting event from EDT during painting handling does not get processed immediately, so leave a lag to the user. My solution here is to coalesce and dispatch the new paint event right after it was posted. This happens only to AWT components. Thanks! -Jonathan -- Best regards, Sergey.
Re: AWT Dev [7u6] Review request for 7112115: Component.getLocationOnScreen() work incorrectly if create window in point (0, 0) on oel
Hi, Denis. I guess that copyright header should be added. 31.05.2012 14:59, Denis S. Fokin wrote: Hi, could you take a look at the next fix. I have moved the test from the closed repository and changed Util.blockTillDisplayed(spinner2); to ((sun.awt.SunToolkit)Toolkit.getDefaultToolkit()).realSync(); because getLocationOnScreen does not guarantee that we will get the last value for component location and blockTillDisplayed uses getLocationOnScreen method. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7112115 Webrev: http://cr.openjdk.java.net/~denis/7112115/webrev.01/ Thank you, Denis. -- Best regards, Sergey.
Re: AWT Dev [7u6] Review request for 7112115: Component.getLocationOnScreen() work incorrectly if create window in point (0, 0) on oel
31.05.2012 16:49, Sergey Bylokhov wrote: Hi, Denis. I guess that copyright header should be added. And probably it should be fixed in 8 first? 31.05.2012 14:59, Denis S. Fokin wrote: Hi, could you take a look at the next fix. I have moved the test from the closed repository and changed Util.blockTillDisplayed(spinner2); to ((sun.awt.SunToolkit)Toolkit.getDefaultToolkit()).realSync(); because getLocationOnScreen does not guarantee that we will get the last value for component location and blockTillDisplayed uses getLocationOnScreen method. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7112115 Webrev: http://cr.openjdk.java.net/~denis/7112115/webrev.01/ Thank you, Denis. -- Best regards, Sergey.
AWT Dev [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing
Hi Everyone, Please review the fix. Notes from the bug and comments: 1. setVisible() should be called at the end of the peers initialization. We can move super.initialize() to the end of the peers initializations. Initialize() was split to initialize() and initializeImpl(). In the initialize() we call initializeImpl and then we call to setVisible(). initializeImpl overridden in subclasses. 2. Invokelater in the initialization/disposing is a tricky. Left it as is. Probably later it will be changed. Comments was updated. 3. replaceSurfacedata() should be moved outside of LWWindowPeer.setVisible() Done. Also duplicate code was extracted to setVisible() method which call setVisibleImpl(). 4. Backbuffer in replaceSurfacedata() should be initialized by clearRect instead of fillrect(composite is important). Done. related to composite. 5. During lwwindowpeer initialization we call two similar methods nativeSetNSWindowAlpha() and setAlphaValue(). nativeSetNSWindowAlpha() removed from CPlatformWindow.java. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 Webrev can be found at: http://cr.openjdk.java.net/~serb/7142091/webrev.00/ -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7112115: Component.getLocationOnScreen() work incorrectly if create window in point (0, 0) on oel
Hi, Denis. Fix looks good. 01.06.2012 15:12, Denis S. Fokin wrote: Hi Artem, Sergey, to make thins simpler I have just added 'throws' clause to methods signatures. This way any problem should lead to a test failure. http://cr.openjdk.java.net/~denis/7112115/webrev.05 Thank you, Denis. On 6/1/2012 12:30 PM, Denis S. Fokin wrote: Hi Artem, in that case I would suggest the next approach. http://cr.openjdk.java.net/~denis/7112115/webrev.03/ Thank you, Denis. On 5/31/2012 8:20 PM, Artem Ananiev wrote: Hi, Denis, the test looks fine. A minor comment: since we don't expect any exceptions in the doTest() method, shouldn't ex be re-thrown then to cause the test failure? Thanks, Artem On 5/31/2012 6:03 PM, Denis S. Fokin wrote: Hi, could you take a look at the next fix. I have moved the test from the closed repository and changed Util.blockTillDisplayed(spinner2); to ((sun.awt.SunToolkit)Toolkit.getDefaultToolkit()).realSync(); because getLocationOnScreen does not guarantee that we will get the last value for component location and blockTillDisplayed uses getLocationOnScreen method. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7112115 Webrev: http://cr.openjdk.java.net/~denis/7112115/webrev.02/ Thank you, Denis. -- Best regards, Sergey.
Re: AWT Dev [7u6] Review request for 7112115: Component.getLocationOnScreen() work incorrectly if create window in point (0, 0) on oel
Hi, Denis. Fix looks good. 01.06.2012 17:11, Denis S. Fokin wrote: Hi, This is a direct backport of the next change-set from jdk 8 into jdk 7u6 http://hg.openjdk.java.net/jdk8/awt-gate/jdk/rev/fd27852f3ea5 Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7112115 Thank you, Denis. -- Best regards, Sergey.
Re: AWT Dev [8] Review request for: 7172722: Latest jdk7u from OSX broke universal build
Fix looks good. Thanks. 04.06.2012 18:48, Anthony Petrov wrote: AWT/MacOSX-port-dev teams, Could I get a review for this one-line fix please? -- best regards, Anthony On 06/01/12 12:47, Henri Gomez wrote: Tested and it works for me. I just produced jdk7u b12 with it : http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u6-b12-20120601.dmg Cheers 2012/5/30 Anthony Petrovanthony.pet...@oracle.com: Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7172722 at: http://cr.openjdk.java.net/~anthony/8-33-MacUniversalBuild-7172722.0/ I've simplified the fix comparing to original Henri's proposal [1] to follow the same pattern as we use with other properties: we simply give the corresponding class fields the same names as to the properties themselves. Henri: please verify if the new patch works for you. [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-May/003191.html -- best regards, Anthony -- Best regards, Sergey.
AWT Dev [8] Review request for 7124244: [macosx] Shaped windows support
Hi Everyone, Please review the fix. Shaped window was implemented as a translucent window with constrained graphics. Now translucent window doesn't use separate BufferedImage as a back buffer. Also alpha value for the swing back buffer was enabled(Shared code changed). Note that shaped windows are affected by this bugs: http://monaco.us.oracle.com/detail.jsf?cr=7124236 - Shadows disappear. - Transparent areas aren't transparent to mouse clicks. http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 - Opacity does not work for non opaque windows. Any suggestions are welcome. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.00 -- Best regards, Sergey.
Re: AWT Dev [7u6] Review request for: 7172722: Latest jdk7u from OSX broke universal build
Hi, Anthony. Fix looks good. 05.06.2012 15:40, Anthony Petrov wrote: Hi Artem and Sergey, Please review a direct back-port of this one-line fix for http://bugs.sun.com/view_bug.do?bug_id=7172722 at: http://cr.openjdk.java.net/~anthony/7u6-11-MacUniversalBuild-7172722.0/ The fix has been verified by Henri Gomez, and has already been pushed to JDK 8. -- best regards, Anthony -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing
Hi Anthony.
Thanks for review. See comments inline.
05.06.2012 19:47, Anthony Petrov wrote:
Hi Sergey,
1. src/macosx/classes/sun/lwawt/LWComponentPeer.java
196 delegate = createDelegate();
197 if (delegate != null) {
198 delegate.setVisible(false);
The call at line 198 looks unnatural here. It looks as if the delegate
is created visible initially which isn't true, is it?
Delegate is visible by default, but our awt peer is not.
2.
204 delegate.setOpaque(true);
Related to the above comment, does this call mean that a delegate is
created non-opaque initially? I feel uncomfortable with these calls.
Do we workaround something with these calls? Can we give them more
appropriate and meaningful names then?
Most of aqua components are non opaque by default, but our awt peer not.
3. src/macosx/classes/sun/lwawt/LWWindowPeer.java
179 updateInsets(platformWindow.getInsets());
The system may report wrong insets before a window is shown on the
screen. Perhaps, instead of initializeImpl() we should introduce
preInitialize() (== current initializeImpl()), and postInitialize()
(to where this, and the subsequent replaceSurfaceData() calls might go.)
Like it was done in XAWT? It is just a nightmare. I assume that
updateInsets() should be called by some of the native callbacks, like
notifyExpose and reshape?
4.
220 protected void setVisibleImpl(final boolean visible) {
221 super.setVisibleImpl(visible);
Why do we remove a call to replaceSurfaceData() in the beginning of
the method?
Before the fix, setVisible() can be called before surface creation, but
after the fix it will be called after.
5.
983 ((Graphics2D)
g).setBackground(getBackground());
I suggest to add an instanceof check before this call.
I guess that Buffered image cannot return something except Graphics2D
6.
227 // invokeLater() can be deleted, but in this case we get
a lag between
228 // windows showing and content painting.
Is the lag so very noticeable? On other platforms we don't actually do
this, and I don't recall any issues about such lags.
Yes The difference is noticeable. So I update the comments and leave it
as is for now.
--
best regards,
Anthony
On 5/31/2012 5:43 PM, Sergey Bylokhov wrote:
Hi Everyone,
Please review the fix.
Notes from the bug and comments:
1. setVisible() should be called at the end of the peers
initialization. We can move super.initialize() to the end of the
peers initializations.
Initialize() was split to initialize() and initializeImpl(). In the
initialize() we call initializeImpl and then we call to setVisible().
initializeImpl overridden in subclasses.
2. Invokelater in the initialization/disposing is a tricky.
Left it as is. Probably later it will be changed. Comments was updated.
3. replaceSurfacedata() should be moved outside of
LWWindowPeer.setVisible()
Done. Also duplicate code was extracted to setVisible() method which
call setVisibleImpl().
4. Backbuffer in replaceSurfacedata() should be initialized by
clearRect instead of fillrect(composite is important).
Done. related to composite.
5. During lwwindowpeer initialization we call two similar methods
nativeSetNSWindowAlpha() and setAlphaValue().
nativeSetNSWindowAlpha() removed from CPlatformWindow.java.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091
Webrev can be found at:
http://cr.openjdk.java.net/~serb/7142091/webrev.00/
--
Best regards, Sergey.
Re: AWT Dev [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing
The system may report wrong insets before a window is shown on the
screen. Perhaps, instead of initializeImpl() we should introduce
preInitialize() (== current initializeImpl()), and postInitialize()
(to where this, and the subsequent replaceSurfaceData() calls might go.)
In this case In current implementation it works wrong too, because it
can be called when the window initially invisible.
05.06.2012 19:47, Anthony Petrov wrote:
Hi Sergey,
1. src/macosx/classes/sun/lwawt/LWComponentPeer.java
196 delegate = createDelegate();
197 if (delegate != null) {
198 delegate.setVisible(false);
The call at line 198 looks unnatural here. It looks as if the delegate
is created visible initially which isn't true, is it?
2.
204 delegate.setOpaque(true);
Related to the above comment, does this call mean that a delegate is
created non-opaque initially? I feel uncomfortable with these calls.
Do we workaround something with these calls? Can we give them more
appropriate and meaningful names then?
3. src/macosx/classes/sun/lwawt/LWWindowPeer.java
179 updateInsets(platformWindow.getInsets());
The system may report wrong insets before a window is shown on the
screen. Perhaps, instead of initializeImpl() we should introduce
preInitialize() (== current initializeImpl()), and postInitialize()
(to where this, and the subsequent replaceSurfaceData() calls might go.)
4.
220 protected void setVisibleImpl(final boolean visible) {
221 super.setVisibleImpl(visible);
Why do we remove a call to replaceSurfaceData() in the beginning of
the method?
5.
983 ((Graphics2D)
g).setBackground(getBackground());
I suggest to add an instanceof check before this call.
6.
227 // invokeLater() can be deleted, but in this case we get
a lag between
228 // windows showing and content painting.
Is the lag so very noticeable? On other platforms we don't actually do
this, and I don't recall any issues about such lags.
--
best regards,
Anthony
On 5/31/2012 5:43 PM, Sergey Bylokhov wrote:
Hi Everyone,
Please review the fix.
Notes from the bug and comments:
1. setVisible() should be called at the end of the peers
initialization. We can move super.initialize() to the end of the
peers initializations.
Initialize() was split to initialize() and initializeImpl(). In the
initialize() we call initializeImpl and then we call to setVisible().
initializeImpl overridden in subclasses.
2. Invokelater in the initialization/disposing is a tricky.
Left it as is. Probably later it will be changed. Comments was updated.
3. replaceSurfacedata() should be moved outside of
LWWindowPeer.setVisible()
Done. Also duplicate code was extracted to setVisible() method which
call setVisibleImpl().
4. Backbuffer in replaceSurfacedata() should be initialized by
clearRect instead of fillrect(composite is important).
Done. related to composite.
5. During lwwindowpeer initialization we call two similar methods
nativeSetNSWindowAlpha() and setAlphaValue().
nativeSetNSWindowAlpha() removed from CPlatformWindow.java.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091
Webrev can be found at:
http://cr.openjdk.java.net/~serb/7142091/webrev.00/
--
Best regards, Sergey.
Re: AWT Dev [8] Review request for 7124244: [macosx] Shaped windows support
05.06.2012 19:05, Anthony Petrov написал: Hi Sergey, A couple of comments: 1. src/macosx/classes/sun/lwawt/LWWindowPeer.java 576 //flushOnscreenGraphics(); There's no any explanation as to why this line is commented out. Could you either add a remark in the code, or delete this line altogether? Yes. Thanks. 2. How does the fix affect the performance of non-opaque (and opaque, too) windows? In general a non-opaque window should work better just because now it doesn't use raw BufferedImage. Opaque window should be affected only by changes in RepaintManager(). -- best regards, Anthony On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: Hi Everyone, Please review the fix. Shaped window was implemented as a translucent window with constrained graphics. Now translucent window doesn't use separate BufferedImage as a back buffer. Also alpha value for the swing back buffer was enabled(Shared code changed). Note that shaped windows are affected by this bugs: http://monaco.us.oracle.com/detail.jsf?cr=7124236 - Shadows disappear. - Transparent areas aren't transparent to mouse clicks. http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 - Opacity does not work for non opaque windows. Any suggestions are welcome. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.00 -- Best regards, Sergey.
Re: AWT Dev [8] Request for review: 7092551 Double-click in TextField sets caret to the beginning
Hi Alexander. Fix looks good to me. 23.05.2012 14:34, Alexander Scherbatiy wrote: Could one more person review the fix? I need at least two reviewers before pushing it. Thanks, Alexandr. On 4/26/2012 2:03 PM, Alexander Scherbatiy wrote: Could someone else review the fix? I need at least two reviewers before pushing it. Webrev: http://cr.openjdk.java.net/~alexsch/7092551/webrev.01/ Thanks, Alexandr. On 4/13/2012 5:59 PM, Oleg Pekhovskiy wrote: Looks good for me. Thanks, OIeg. On 4/06/2012 3:45 PM, Alexander Scherbatiy wrote: Hello, Please review a fix for: CR 7092551 Double-click in TextField sets caret to the beginning http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7092551 Webrev:http://cr.openjdk.java.net/~alexsch/7092551/webrev.01/ http://cr.openjdk.java.net/%7Ealexsch/7092551/webrev.01/ A Double-click in TextField does not work because the TextField is based on the windows EDIT control which does not have EM_FINDWORDBREAK method. A solution is to use the RICHEDIT control instead of EDIT. Because the TextArea also is based on the RICHEDIT control it is possible to make some unification between AwtTextField and AwtTextArea classes. Changes: 1) Moving getting RICHEDIT class name from the TextArea to TextComponent 2) Updating TextField Create method to use the TextArea workarounds. 3) Moving OLE callbacks class defenition and creation to the TextComponent (both classes TextField and TextArea now use it) 4) EditGetCharFromPos method bodies are differenet for TextField and TextArea. Using the old one in the TextField leads to the EXCEPTION_ACCESS_VIOLATION. So using the one from the TextArea and moving it to TextComponent. The issue 7092551 (Double-click in TextField sets caret to the beginning) is resolved. Issues: 5) Setting editable for TextField to false does not show gray background. Moving workaround for the Enable, SetColor and SetBackground methods definitions from TextArea to TextComponent 6) Setting an echo char for TextField and double click selects only part of the echoed text. Addding checking the echo char to the HandleEvent method where a text is selected. 7) Adding issue 6417581 workaround to EditSetSel method of the TextField component. There is one more workaround 5003402 for TextArea control which needs to enable the automatic scrolling and there is no need to use it in the TextField. 8) Move PreProcessMsg method from the TextArea to TextComponent to workaround filtering the WM_LBUTTONUP after WM_LBUTTONDBLCLK for RichEdit 1.0 9) CR 6480547 is not reproduced with the RICHEDIT control. Removing using initialRescroll workaround from the TextField. Not need to override the Reshape method in the Textfield. Requested changes: 10) NOERROR is changed to S_OK 11) The OleCallback is not deleted explicitly in the OleCallback::Release() method. Only number of the object references is returned. 12) if-else block in the OleCallback::QueryInterface method is unified. 13) Because only the RichEdit 2.0 control is used (and it is not necessary to support the RichEdit 1.0) the AwtTextArea::PreProcessMsg method that tries to avoid issue with the WM_LBUTTONUP event after double click is removed. The right behavior is that there are 2 WM_LBUTTONUP events after the WM_LBUTTONDOWN during the mouse double click. So the RichEdit 2.0 control has a right behavior. However the RichEdit 1.0 generates a pair of events WM_LBUTTONDOWN, WM_LBUTTONUP during the double click. 14) Methods merging - The create method is unified and moved to the AwtTextComponent class. - I do not merge the HandleEvent method. They are quite similar in both classes AwtTextField and AwtTextArea. However there are differences in some 'if' branches. Thanks, Alexandr. -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7124244: [macosx] Shaped windows support
Hi, Anthony. yes I will make the new version soon. 09.06.2012 17:15, Anthony Petrov wrote: Thanks for the comments. Will there be an updated version of the fix? -- best regards, Anthony On 6/5/2012 10:25 PM, Sergey Bylokhov wrote: 05.06.2012 19:05, Anthony Petrov написал: Hi Sergey, A couple of comments: 1. src/macosx/classes/sun/lwawt/LWWindowPeer.java 576 //flushOnscreenGraphics(); There's no any explanation as to why this line is commented out. Could you either add a remark in the code, or delete this line altogether? Yes. Thanks. 2. How does the fix affect the performance of non-opaque (and opaque, too) windows? In general a non-opaque window should work better just because now it doesn't use raw BufferedImage. Opaque window should be affected only by changes in RepaintManager(). -- best regards, Anthony On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: Hi Everyone, Please review the fix. Shaped window was implemented as a translucent window with constrained graphics. Now translucent window doesn't use separate BufferedImage as a back buffer. Also alpha value for the swing back buffer was enabled(Shared code changed). Note that shaped windows are affected by this bugs: http://monaco.us.oracle.com/detail.jsf?cr=7124236 - Shadows disappear. - Transparent areas aren't transparent to mouse clicks. http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 - Opacity does not work for non opaque windows. Any suggestions are welcome. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.00 -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing
Hi Anthony.
See my comments inline:
09.06.2012 17:34, Anthony Petrov wrote:
Hi Sergey,
Thanks for clarifications. Please find my comments below.
On 6/5/2012 8:13 PM, Sergey Bylokhov wrote:
3. src/macosx/classes/sun/lwawt/LWWindowPeer.java
179 updateInsets(platformWindow.getInsets());
The system may report wrong insets before a window is shown on the
screen. Perhaps, instead of initializeImpl() we should introduce
preInitialize() (== current initializeImpl()), and postInitialize()
(to where this, and the subsequent replaceSurfaceData() calls might
go.)
Like it was done in XAWT? It is just a nightmare. I assume that
What kind of nightmare do you mean? To me it looks logical to perform
some tasks before, and some other tasks after disaplying a component.
Hence the need for per- and post- initializers.
Because in general nobody know correct place for initialization.
Moreover we can do something after component showing in setVisble(true)
only.
updateInsets() should be called by some of the native callbacks, like
notifyExpose and reshape?
Nope. It's only called from the initialize() method once since on the
Mac insets never change. Therefore, it is critical to call it only
after showing the window on the screen.
But what happens when the peer is invisible by default? Probably the
better place for updateInsets is setVisible()?
On 6/5/2012 10:17 PM, Sergey Bylokhov wrote:
In this case In current implementation it works wrong too, because it
can be called when the window initially invisible.
So far, it works fine. Please run insets-related tests (simply all
automatic tests for Window, Frame, and Dialog both open and closed) to
makes sure they pass.
See previous comment.
4.
220 protected void setVisibleImpl(final boolean visible) {
221 super.setVisibleImpl(visible);
Why do we remove a call to replaceSurfaceData() in the beginning of
the method?
Before the fix, setVisible() can be called before surface creation,
but after the fix it will be called after.
Could you clarify this further please? What exactly is the reason to
move the replaceSurfaceData() call from setVisible() to initializeImpl()?
Just because it is unnecessary in setVisble() because surface already
created at the end of LWWindow.initializeImpl(). Why we should try to
replace surface each time in setVisible()?
5.
983 ((Graphics2D)
g).setBackground(getBackground());
I suggest to add an instanceof check before this call.
I guess that Buffered image cannot return something except Graphics2D
I guess so too. Nevertheless, I still suggest to add such a check.
ok I will add.
6.
227 // invokeLater() can be deleted, but in this case we
get a lag between
228 // windows showing and content painting.
Is the lag so very noticeable? On other platforms we don't actually
do this, and I don't recall any issues about such lags.
Yes The difference is noticeable. So I update the comments and leave
it as is for now.
Interesting. This needs to be investigated, perhaps under a separate CR.
I will create new CR.
--
best regards,
Anthony
--
best regards,
Anthony
On 5/31/2012 5:43 PM, Sergey Bylokhov wrote:
Hi Everyone,
Please review the fix.
Notes from the bug and comments:
1. setVisible() should be called at the end of the peers
initialization. We can move super.initialize() to the end of the
peers initializations.
Initialize() was split to initialize() and initializeImpl(). In the
initialize() we call initializeImpl and then we call to
setVisible(). initializeImpl overridden in subclasses.
2. Invokelater in the initialization/disposing is a tricky.
Left it as is. Probably later it will be changed. Comments was
updated.
3. replaceSurfacedata() should be moved outside of
LWWindowPeer.setVisible()
Done. Also duplicate code was extracted to setVisible() method
which call setVisibleImpl().
4. Backbuffer in replaceSurfacedata() should be initialized by
clearRect instead of fillrect(composite is important).
Done. related to composite.
5. During lwwindowpeer initialization we call two similar methods
nativeSetNSWindowAlpha() and setAlphaValue().
nativeSetNSWindowAlpha() removed from CPlatformWindow.java.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091
Webrev can be found at:
http://cr.openjdk.java.net/~serb/7142091/webrev.00/
--
Best regards, Sergey.
AWT Dev [7u6] Request for review: 7147055 [macosx] Cursors are changing over a blocked window; also blinking
Hi Everyone, This is a back port from jdk 8 to jdk 7u6. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147055 Webrev can be found at: http://cr.openjdk.java.net/~serb/7147055/webrev.00/ jdk8 changeset: hg.openjdk.java.net/jdk8/awt/jdk/rev/0feee4541f67 -- Best regards, Sergey.
AWT Dev [7u6] Request for review: 7150105 [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor.
Hi Everyone, This is a back port from jdk 8 to jdk 7u6. Review: http://mail.openjdk.java.net/pipermail/awt-dev/2012-April/002502.html Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150105 Webrev can be found at: http://cr.openjdk.java.net/~serb/7150105/webrev.00/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/933ea89bec06 -- Best regards, Sergey.
Re: AWT Dev [7u6] Request for review: 7150105 [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor.
Thanks, Anthony. Does anybody has a chance to review it? On 18.06.2012 19:11, Anthony Petrov wrote: Looks good. -- best regards, Anthony On 06/15/12 15:40, Sergey Bylokhov wrote: Hi Everyone, This is a back port from jdk 8 to jdk 7u6. Review: http://mail.openjdk.java.net/pipermail/awt-dev/2012-April/002502.html Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150105 Webrev can be found at: http://cr.openjdk.java.net/~serb/7150105/webrev.00/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/933ea89bec06 -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing
Hello, new version of the fix: http://cr.openjdk.java.net/~serb/7142091/webrev.01/ - invokeLater was removed from setVisible and dispose. - instanceof Graphics2D was added. Run some awt related jck and regression tests, no new issues found. On 18.06.2012 19:13, Artem Ananiev wrote: Hi, Sergey, some minor comments (may be unrelated to the fix): 1. LWComponentPeer.setVisible() can be made final. Do expect any subclass to override it instead of setVisibleImpl()? It is overriden in CPrinterDialogPeer. 2. invokeLater() in LWWindowPeer.setVisibleImpl(): I realize this is really painful issue, but I'd vote for removing this workaround. It would result in faster startup (although, the window will be solid gray for some time), and make LWAWT code similar to what we have on other platforms. removed Then next step will to minimize the delay between showing the window and painting its content. 3. LWWindowPeer.replaceSurfaceData(): what are benefits of setBackground() + clearRect() over setColor() + fillRect()? Although we always expect the Graphics object to be Graphics2D instance, this unconditional cast doesn't look great. done Thanks, Artem On 5/31/2012 5:43 PM, Sergey Bylokhov wrote: Hi Everyone, Please review the fix. Notes from the bug and comments: 1. setVisible() should be called at the end of the peers initialization. We can move super.initialize() to the end of the peers initializations. Initialize() was split to initialize() and initializeImpl(). In the initialize() we call initializeImpl and then we call to setVisible(). initializeImpl overridden in subclasses. 2. Invokelater in the initialization/disposing is a tricky. Left it as is. Probably later it will be changed. Comments was updated. 3. replaceSurfacedata() should be moved outside of LWWindowPeer.setVisible() Done. Also duplicate code was extracted to setVisible() method which call setVisibleImpl(). 4. Backbuffer in replaceSurfacedata() should be initialized by clearRect instead of fillrect(composite is important). Done. related to composite. 5. During lwwindowpeer initialization we call two similar methods nativeSetNSWindowAlpha() and setAlphaValue(). nativeSetNSWindowAlpha() removed from CPlatformWindow.java. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 Webrev can be found at: http://cr.openjdk.java.net/~serb/7142091/webrev.00/ -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7124244: [macosx] Shaped windows support
Hi, Artem, Anthony. New version of the fix: http://cr.openjdk.java.net/~serb/7124244/webrev.01 13.06.2012 06:30, Artem Ananiev wrote: Hi, Sergey, a few minor comments: 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are corresponding checks just above. done. 2. invalidateShadow() is not used in sun.lwawt, so it can be just a method in CPlatformWindow. BTW, do you have any ideas, why CGLayer holds a reference to LWWindowPeer, not to CPlatformWindow? done. 3. As we don't expect isSwingBackbufferTranslucencySupported() to return different values, it would be fine to call it only once to avoid possible perf regressions. done. Thanks, Artem On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: Hi Everyone, Please review the fix. Shaped window was implemented as a translucent window with constrained graphics. Now translucent window doesn't use separate BufferedImage as a back buffer. Also alpha value for the swing back buffer was enabled(Shared code changed). Note that shaped windows are affected by this bugs: http://monaco.us.oracle.com/detail.jsf?cr=7124236 - Shadows disappear. - Transparent areas aren't transparent to mouse clicks. http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 - Opacity does not work for non opaque windows. Any suggestions are welcome. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.00 -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7124244: [macosx] Shaped windows support
Hi, Artem, Anthony.
New version of the fix:
http://cr.openjdk.java.net/~serb/7124244/webrev.02/
25.06.2012 06:02, Anthony Petrov wrote:
Hi Sergey,
The fix looks good overall. Just two comments:
1. src/macosx/classes/sun/lwawt/LWWindowPeer.java
987 if (oldBB != null) {
988 backBuffer = (BufferedImage)
platformWindow.createBackBuffer();
Since we never create a back buffer in JDK 8 currently, I suggest to
comment this code out, and add a remark mentioning a CR number that
should make use of the code in the future.
done
2. src/share/classes/javax/swing/RepaintManager.java
1501 Graphics2D g2d = (Graphics2D) osg.create();
1502 g2d.setBackground(c.getBackground());
1503 g2d.clearRect(x, y, bw, bh);
1504 g2d.dispose();
Please use the try {} finally {} pattern to dispose the G2D object.
The same comment applies to the lines 1510-1513.
fixed
--
best regards,
Anthony
On 06/25/12 14:42, Sergey Bylokhov wrote:
Hi, Artem, Anthony.
New version of the fix:
http://cr.openjdk.java.net/~serb/7124244/webrev.01
13.06.2012 06:30, Artem Ananiev wrote:
Hi, Sergey,
a few minor comments:
1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in
CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are
corresponding checks just above.
done.
2. invalidateShadow() is not used in sun.lwawt, so it can be just a
method in CPlatformWindow. BTW, do you have any ideas, why CGLayer
holds a reference to LWWindowPeer, not to CPlatformWindow?
done.
3. As we don't expect isSwingBackbufferTranslucencySupported() to
return different values, it would be fine to call it only once to
avoid possible perf regressions.
done.
Thanks,
Artem
On 6/4/2012 7:49 PM, Sergey Bylokhov wrote:
Hi Everyone,
Please review the fix.
Shaped window was implemented as a translucent window with constrained
graphics. Now translucent window doesn't use separate BufferedImage
as a
back buffer. Also alpha value for the swing back buffer was
enabled(Shared code changed).
Note that shaped windows are affected by this bugs:
http://monaco.us.oracle.com/detail.jsf?cr=7124236
- Shadows disappear.
- Transparent areas aren't transparent to mouse clicks.
http://monaco.sfbay.sun.com/detail.jsf?cr=7172431
- Opacity does not work for non opaque windows.
Any suggestions are welcome.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244
Webrev can be found at:
http://cr.openjdk.java.net/~serb/7124244/webrev.00
--
Best regards, Sergey.
Re: AWT Dev [8] Review request for 7124244: [macosx] Shaped windows support
Hi, Artem. New version of the fix. http://cr.openjdk.java.net/~serb/7124244/webrev.03/ 25.06.2012 08:16, Artem Ananiev wrote: Hi, Sergey, a few minor comments: 1. CPlatformWindow.java: invalidateShadow() in native is ready to be called on any thread, so what's the reason behind invokeLater() here? It is used to postpone shadow invalidating. 2. RepaintManager.java: the new field should better be named volatileBufferType. done 3. LWComponentPeer.applyShape() is a peer method, which accepts user-supplied object (right now it's constructed from Shape in AWT internal code, but nothing prevents users from calling this method directly), so it should be stored as a copy, not as a reference. done Thanks, Artem On 6/25/2012 2:42 PM, Sergey Bylokhov wrote: Hi, Artem, Anthony. New version of the fix: http://cr.openjdk.java.net/~serb/7124244/webrev.01 13.06.2012 06:30, Artem Ananiev wrote: Hi, Sergey, a few minor comments: 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are corresponding checks just above. done. 2. invalidateShadow() is not used in sun.lwawt, so it can be just a method in CPlatformWindow. BTW, do you have any ideas, why CGLayer holds a reference to LWWindowPeer, not to CPlatformWindow? done. 3. As we don't expect isSwingBackbufferTranslucencySupported() to return different values, it would be fine to call it only once to avoid possible perf regressions. done. Thanks, Artem On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: Hi Everyone, Please review the fix. Shaped window was implemented as a translucent window with constrained graphics. Now translucent window doesn't use separate BufferedImage as a back buffer. Also alpha value for the swing back buffer was enabled(Shared code changed). Note that shaped windows are affected by this bugs: http://monaco.us.oracle.com/detail.jsf?cr=7124236 - Shadows disappear. - Transparent areas aren't transparent to mouse clicks. http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 - Opacity does not work for non opaque windows. Any suggestions are welcome. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.00 -- Best regards, Sergey.
AWT Dev hg: jdk8/awt/jdk: 7142091: [macosx] RFE: Refactoring of peer initialization/disposing
Changeset: 7d1eae258183 Author:serb Date: 2012-06-26 13:46 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7d1eae258183 7142091: [macosx] RFE: Refactoring of peer initialization/disposing Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWButtonPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWChoicePeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m
AWT Dev [7u6] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing
Hi Everyone, Please review the fix. Notes from the bug and comments: 1. setVisible() should be called at the end of the peers initialization. We can move super.initialize() to the end of the peers initializations. Initialize() was split to initialize() and initializeImpl(). In the initialize() we call initializeImpl and then we call to setVisible(). initializeImpl overridden in subclasses. 2. Invokelater in the initialization/disposing is a tricky. Removed. 3. replaceSurfacedata() should be moved outside of LWWindowPeer.setVisible() Done. Also duplicate code was extracted to setVisible() method which call setVisibleImpl(). 4. Backbuffer in replaceSurfacedata() should be initialized by clearRect instead of fillrect(composite is important). Done. related to composite. 5. During lwwindowpeer initialization we call two similar methods nativeSetNSWindowAlpha() and setAlphaValue(). nativeSetNSWindowAlpha() removed from CPlatformWindow.java. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 Webrev can be found at: http://cr.openjdk.java.net/~serb/7142091/webrev.01/ Also note that CR 7177173 depends from this one. -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7124244: [macosx] Shaped windows support
Hi Artem, Anthony. Updated webrev. http://cr.openjdk.java.net/~serb/7124244/webrev.04/ - CPlatformEmbeddedFrame now use correct backbuffer. - For simplification, creation of the backbuffer was reverted back. 25.06.2012 19:16, Artem Ananiev wrote: Hi, Sergey, a few minor comments: 1. CPlatformWindow.java: invalidateShadow() in native is ready to be called on any thread, so what's the reason behind invokeLater() here? 2. RepaintManager.java: the new field should better be named volatileBufferType. 3. LWComponentPeer.applyShape() is a peer method, which accepts user-supplied object (right now it's constructed from Shape in AWT internal code, but nothing prevents users from calling this method directly), so it should be stored as a copy, not as a reference. Thanks, Artem On 6/25/2012 2:42 PM, Sergey Bylokhov wrote: Hi, Artem, Anthony. New version of the fix: http://cr.openjdk.java.net/~serb/7124244/webrev.01 13.06.2012 06:30, Artem Ananiev wrote: Hi, Sergey, a few minor comments: 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are corresponding checks just above. done. 2. invalidateShadow() is not used in sun.lwawt, so it can be just a method in CPlatformWindow. BTW, do you have any ideas, why CGLayer holds a reference to LWWindowPeer, not to CPlatformWindow? done. 3. As we don't expect isSwingBackbufferTranslucencySupported() to return different values, it would be fine to call it only once to avoid possible perf regressions. done. Thanks, Artem On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: Hi Everyone, Please review the fix. Shaped window was implemented as a translucent window with constrained graphics. Now translucent window doesn't use separate BufferedImage as a back buffer. Also alpha value for the swing back buffer was enabled(Shared code changed). Note that shaped windows are affected by this bugs: http://monaco.us.oracle.com/detail.jsf?cr=7124236 - Shadows disappear. - Transparent areas aren't transparent to mouse clicks. http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 - Opacity does not work for non opaque windows. Any suggestions are welcome. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.00 -- Best regards, Sergey.
AWT Dev hg: jdk8/awt/jdk: 2 new changesets
Changeset: f1a90ee31b38 Author:serb Date: 2012-07-04 14:38 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f1a90ee31b38 7124244: [macosx] Shaped windows support Reviewed-by: anthony, art ! src/macosx/classes/sun/java2d/opengl/CGLLayer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWRepaintArea.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTWindow.m ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 80c592c9458e Author:serb Date: 2012-07-04 15:36 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/80c592c9458e 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar Reviewed-by: anthony, art ! src/macosx/classes/com/apple/laf/AquaPanelUI.java ! src/macosx/classes/com/apple/laf/AquaRootPaneUI.java ! src/macosx/classes/com/apple/laf/AquaToolBarUI.java ! src/macosx/classes/com/apple/laf/AquaUtils.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/share/classes/javax/swing/JViewport.java
Re: AWT Dev [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7
Hi,Anthony.
I just point to the same name isZoomed, which contains different state:
first is true for this.normalBounds == null and the second true for
this.normalBounds != null.
This is strange.
I believe that correct code should be isZoomed = isZoomed();?
04.07.2012 19:15, Anthony Petrov wrote:
Hi Sergey,
Thanks for the review.
On 7/4/2012 7:07 PM, Sergey Bylokhov wrote:
Why there are two different methods for isZoomed?
481 final boolean isZoomed = *this.normalBounds == null*;
Here we determine a new state that needs to be set to an undecorated
window. This is what isZoomed() will return after the zoom() method
returns.
But in the method we use another code.
471 private boolean isZoomed() {
472 return zoomed || *this.normalBounds != null*;
473 }
This is a method that returns the current zoomed state for any window
regardless whether it is decorated or not.
Probably it can be unified?
No. These are completely different operations. We might change the
first line to final boolean isZoomed = !isZoomed();, but the current
code looks a lot clearer to me.
--
best regards,
Anthony
04.07.2012 18:54, Anthony Petrov wrote:
Hello,
Please review a fix for
http://bugs.sun.com/view_bug.do?bug_id=7177173 at:
http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/
The bug synopsis may sound misleading: the original problem with
applying the extended state after showing a frame has been resolved
a while back with another fix. The only issue currently left is that
the state is reset when a frame is disposed/hidden, which prevents
apps from tracking the last known state of a window.
With this fix we avoid canceling/reapplying the maximized state to
windows on each showing/hiding operation. Instead we track the state
in the CPlatformWindow instance, and apply it on showing of the
window if the state differs from what shared code expects. The
behavior now matches that of Apple JDK (including handling of the
ICONIFIED state).
--
best regards,
Anthony
--
Best regards, Sergey.
--
Best regards, Sergey.
Re: AWT Dev [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7
Hi, Anthony.
Fix looks good.
04.07.2012 19:30, Anthony Petrov wrote:
Hi Sergey,
Please find an updated webrev at:
http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.2/
I renamed the local variable from isZoomed to doZoom.
--
best regards,
Anthony
On 7/4/2012 7:26 PM, Sergey Bylokhov wrote:
Hi,Anthony.
I just point to the same name isZoomed, which contains different
state:
first is true for this.normalBounds == null and the second true
for this.normalBounds != null.
This is strange.
I believe that correct code should be isZoomed = isZoomed();?
04.07.2012 19:15, Anthony Petrov wrote:
Hi Sergey,
Thanks for the review.
On 7/4/2012 7:07 PM, Sergey Bylokhov wrote:
Why there are two different methods for isZoomed?
481 final boolean isZoomed = *this.normalBounds == null*;
Here we determine a new state that needs to be set to an undecorated
window. This is what isZoomed() will return after the zoom() method
returns.
But in the method we use another code.
471 private boolean isZoomed() {
472 return zoomed || *this.normalBounds != null*;
473 }
This is a method that returns the current zoomed state for any
window regardless whether it is decorated or not.
Probably it can be unified?
No. These are completely different operations. We might change the
first line to final boolean isZoomed = !isZoomed();, but the
current code looks a lot clearer to me.
--
best regards,
Anthony
04.07.2012 18:54, Anthony Petrov wrote:
Hello,
Please review a fix for
http://bugs.sun.com/view_bug.do?bug_id=7177173 at:
http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/
The bug synopsis may sound misleading: the original problem with
applying the extended state after showing a frame has been
resolved a while back with another fix. The only issue currently
left is that the state is reset when a frame is disposed/hidden,
which prevents apps from tracking the last known state of a window.
With this fix we avoid canceling/reapplying the maximized state to
windows on each showing/hiding operation. Instead we track the
state in the CPlatformWindow instance, and apply it on showing of
the window if the state differs from what shared code expects. The
behavior now matches that of Apple JDK (including handling of the
ICONIFIED state).
--
best regards,
Anthony
--
Best regards, Sergey.
--
Best regards, Sergey.
Re: AWT Dev [7u6] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7
Hi, Anthony. Fix looks good. 06.07.2012 15:23, Anthony Petrov wrote: Hi Sergey, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7177173 at: http://cr.openjdk.java.net/~anthony/7u6-17-MaximizedBoth-7177173.0/ This is a 100% direct back-port of the same fix from JDK 8. -- best regards, Anthony -- Best regards, Sergey.
AWT Dev [7u6] Review request for 7124244: [macosx] Shaped windows support
Hi Everyone, Please review the fix. This is a direct backport from JDK 8 to 7u6. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.04/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f1a90ee31b38 -- Best regards, Sergey.
AWT Dev [7u6] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar
Hi Everyone, Please review the fix. This is a direct backport from JDK 8 to 7u6. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124513/webrev.01 jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/80c592c9458e -- Best regards, Sergey.
Re: AWT Dev [7u6] Review request for 7162144: Missing AWT thread in headless mode in 7u4 b20
Hi, Anthony. Fix looks good. 10.07.2012 13:52, Anthony Petrov wrote: Hi Sergey and Oleg, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7162144 at: http://cr.openjdk.java.net/~anthony/7u6-16-missingAWTThread-7162144.0/ Notes: 1. To prevent a hang, invokeAndWait() will throw InterruptedException when the EDT is interrupted. NetBeans team confirms that this solution helps resolve their issue. 2. There's no easy way to test it, so there's not a regression test. However, the bug contains a link to a huge test case that I used to verify this fix. 3. We're fixing this in 7u6 first, because we're currently unable to test it properly with JDK 8 due to broken headless mode (blocked by an open JVM bug). -- best regards, Anthony -- Best regards, Sergey.
AWT Dev [8] Review request for 7170657: [macosx] There seems to be no keyboard/mouse action to select non-contiguous items in List
Hi Everyone, Please review the fix. Bug in SwingUtilities.convertMouseEvent().This method does not convert extended state of the event. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170657 Webrev can be found at: http://cr.openjdk.java.net/~serb/7170657/webrev.00 -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7170657: [macosx] There seems to be no keyboard/mouse action to select non-contiguous items in List
Hi, Pavel. Thanks for review. See comments inline 12.07.2012 20:26, Pavel Porvatov wrote: Hi Sergey, The fix looks good. Could you please remove unnecessary code from the test like: 1. @run main/othervm bug7170657 done 2. The FAILED field: you can throw exception from the fail method In this case we skip part of the test. Useful for debug. 3. What is the reason to use final here: public final class? I do not think that someone will want to be inherited from it. I just make all classes final by default. New version of the fix: http://cr.openjdk.java.net/~serb/7170657/webrev.01/ Regards, Pavel Hi Everyone, Please review the fix. Bug in SwingUtilities.convertMouseEvent().This method does not convert extended state of the event. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170657 Webrev can be found at: http://cr.openjdk.java.net/~serb/7170657/webrev.00 -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7184365 closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails
Hi, Alexander. Can we remove these checks from the peers and move them to TextComponent.setText()? 20.07.2012 17:05, Alexander Scherbatiy wrote: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184365 webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.00/ The failed test expects that TextListener is not invoked after changing empty text to empty for the TextArea and is invoked for the TextField. After switching the EDIT control to RICHEDIT on windows for the TextField the TextListener listener is not invoked for both TextField and TextArea in this case. To be consistent with other platforms the fix: - Moves the checking for new empty text from the LWTextAreaPeer to LWTextComponentPeer on Mac OS X - Adds the empty text checking to the XTextFieldPeer (the XTextAreaPeer class has already has one) on Linux Thanks, Alexandr. -- Best regards, Sergey.
Re: AWT Dev [7u6] Review request for 7184401: JDk7u6 Missing main menu bar in Netbeans after fix for 7162144
Thanks! Phil 20.07.2012 21:15, Phil Race wrote: Looks ok to me .. -phil. On 7/20/2012 10:05 AM, Sergey Bylokhov wrote: I need one more reviewer. Artem thanks. 20.07.2012 19:56, Artem Ananiev wrote: Sergey, the fix looks good. Thanks, Artem On 7/20/2012 3:24 PM, Sergey Bylokhov wrote: Does anybody have a chance to review it? Thanks. 19.07.2012 18:53, Sergey Bylokhov wrote: Hi Everyone, Please review the fix. This is rollback of 7162144. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184401 Webrev can be found at: http://cr.openjdk.java.net/~serb/7184401/webrev.00 -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7185512 The printout doesn't match image on screen.
Hi, Alexander. Does we get correct text in the textfield in the testcase from the CR(printAll)? 23.07.2012 14:14, Alexander Scherbatiy wrote: Please review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ After switching the EDIT control to RICHEDIT for the TextField component the WM_PRINTCLIENT message should also be handled in the same way as it is done for the TextArea. The WM_PRINTCLIENT message handling is moved to the AwtTextComponent class in the fix. Thanks, Alexandr. -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7185512 The printout doesn't match image on screen.
Fix looks good. 23.07.2012 16:57, Alexander Scherbatiy wrote: On 7/23/2012 2:29 PM, Sergey Bylokhov wrote: Hi, Alexander. Does we get correct text in the textfield in the testcase from the CR(printAll)? I think it can be treated as a separated issue that the RICHEDIT control with the current settings in the AwtTextField class does not show text after CR symbol. It does not relate to the printing functionality. Thanks, Alexandr. 23.07.2012 14:14, Alexander Scherbatiy wrote: Please review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ After switching the EDIT control to RICHEDIT for the TextField component the WM_PRINTCLIENT message should also be handled in the same way as it is done for the TextArea. The WM_PRINTCLIENT message handling is moved to the AwtTextComponent class in the fix. Thanks, Alexandr. -- Best regards, Sergey.
Re: AWT Dev [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session)
Hi, Alexander. Fix looks good 23.07.2012 17:28, Alexander Zuev wrote: On 7/23/12 17:19, Artem Ananiev wrote: On 7/23/2012 2:53 PM, Alexander Zuev wrote: Artem, these native methods should not be called according to the logic of the class so we shouldn't safeguard them. Could you elaborate on that, please? Sure. The only native method that is not related to drag and drop functionality (which can not be instantiated in headless mode anyways) is private native String formatForIndex(long index); It is being called from the protected method getNativeForFormat(long format) which, in turn, being called by the drag-related methods or from public getters that check the index to be in the valid borders. Since we do not register any native-backed flavors in the set this native method will not be called in headless mode. I will create the sub-cr against the jdk8. Thanks! Artem WBR, Alex On 7/23/12 14:41, Artem Ananiev wrote: Hi, Alex, (cross-posting to awt-dev) I see several other native methods in CDataTransferer, e.g. formatForIndex(). Could you confirm, they cannot be called in the headless mode, so there is no need to protect them with headless check, please? Could you also file a SubCR against JDK8 with the idea we discussed offline: create a new CHeadlessDataTransferer class to use in the headless mode instead of CDataTransferer + headless checks, please? Thanks, Artem On 7/23/2012 1:09 PM, Alexander Zuev wrote: Hello, please review my fix 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) CR description can be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 Webrev with the proposed change can be seen here: http://cr.openjdk.java.net/~kizune/7184951/webrev.00 The problem here lays somewhere deep in the Toolkit life cycle on Mac OS X - at the time we initialize datatransfer the Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later when we trying to use it it returns HeadlessToolkit. That's definitely wrong but at this stage it's too risky to fiddle with the life cycle itself so this is a hotfix that deals with the fallout of the actual error. The fix for jdk8 should be different. With best regards, Alex -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7184365 closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails
Hi, Alexander. Fix looks good. 25.07.2012 18:50, Alexander Scherbatiy wrote: On 7/24/2012 4:32 PM, Sergey Bylokhov wrote: Hi, Alexander. A few comments: - LWTextComponentPeer.setText can be final now. - Behavior of TextComponent.setText(null) getText() were changed for null values if peer does not exists. Could you review the updated version where the problems listed above are fixed: webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.02/ Thanks, Alexandr. 24.07.2012 16:17, Alexander Scherbatiy wrote: On 7/20/2012 5:28 PM, Sergey Bylokhov wrote: Hi, Alexander. Can we remove these checks from the peers and move them to TextComponent.setText()? I see. Could you review the updated fix? The empty text check is removed from the LWTextAreaPeer an XTextAreaPeer and moved to the TextComponent. webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.01/ Thanks, Alexandr. 20.07.2012 17:05, Alexander Scherbatiy wrote: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184365 webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.00/ The failed test expects that TextListener is not invoked after changing empty text to empty for the TextArea and is invoked for the TextField. After switching the EDIT control to RICHEDIT on windows for the TextField the TextListener listener is not invoked for both TextField and TextArea in this case. To be consistent with other platforms the fix: - Moves the checking for new empty text from the LWTextAreaPeer to LWTextComponentPeer on Mac OS X - Adds the empty text checking to the XTextFieldPeer (the XTextAreaPeer class has already has one) on Linux Thanks, Alexandr. -- Best regards, Sergey.
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.
AWT Dev [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders
Hi Everyone, Please review the fix. We should support apple.awt.fileDialogForDirectories Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 Webrev can be found at: http://cr.openjdk.java.net/~serb/7161437/webrev.00/ Fix was contributed-by: Marco Dinacci Discussion here: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004295.html -- Best regards, Sergey.
Re: AWT Dev [8] Please review fix for 7177144: [macosx] Drag and drop not working (regression in 7u6)
10.08.2012 16:26, Alexander Zuev wrote:
Hello,
please review my fix for CR 7177144: [macosx] Drag and drop not
working (regression in 7u6)
I still tink we shouldn't move the instanceof check to the earlier
stage since this check may be costly
so it should not be performed unless other possibilities are ruled out
by the less expensive checks.
At least one of them can be moved from coalesceMouseEvent to coalesceEvent
if (e instanceof MouseEvent !(e instanceof
SunDropTargetEvent)) {
}
in cacheEQItem() it executes almost always. Why we should not cache
these events?
Bug description is:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144
Webrev can be found here:
http://cr.openjdk.java.net/~kizune/7177144/webrev.01
With best regards,
Alex
--
Best regards, Sergey.
AWT Dev hg: jdk8/awt/jdk: 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders
Changeset: b41845694f39 Author:serb Date: 2012-08-13 17:43 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b41845694f39 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders Reviewed-by: art, anthony Contributed-by: Marco Dinacci marco.dina...@gmail.com ! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/macosx/native/sun/awt/CFileDialog.h ! src/macosx/native/sun/awt/CFileDialog.m
Re: AWT Dev [8] Please review fix for 7177144: [macosx] Drag and drop not working (regression in 7u6)
Hi, Alexander. Fix looks good. 13.08.2012 18:28, Alexander Zuev wrote: Well, it works this way too and fix is much more compact so here it is - a new version available at http://cr.openjdk.java.net/~kizune/7177144/webrev.03 WBR, Alex On 8/10/12 19:41, Artem Ananiev wrote: Hi, Alex, what about putting the instanceof check to eventToCacheIndex(), under MOUSE_DRAGGED switch, and return -1 for dnd events? We don't cache such unknown events, as well as don't coalesce them. Thanks, Artem On 8/10/2012 4:26 PM, Alexander Zuev wrote: Hello, please review my fix for CR 7177144: [macosx] Drag and drop not working (regression in 7u6) I still tink we shouldn't move the instanceof check to the earlier stage since this check may be costly so it should not be performed unless other possibilities are ruled out by the less expensive checks. Bug description is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 Webrev can be found here: http://cr.openjdk.java.net/~kizune/7177144/webrev.01 With best regards, Alex -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression)
Thanks Leonid. Does anybody has a chance to review it? 08.08.2012 10:20, Leonid Romanov wrote: Looks reasonable. -Original Message- From: Sergey Bylokhov [mailto:sergey.bylok...@oracle.com] Sent: Tuesday, August 07, 2012 3:40 PM To: Leonid Romanov; Mike Swingler; awt-dev@openjdk.java.net; macosx-port-...@openjdk.java.net Subject: [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.
AWT Dev [8] Review request for 7172187 [macosx] JAWT native CALayer not positioned over Canvas
Hi Everyone, Please review the fix. Description of main changes: CPlatformComponent.java: -Unused peer and target references were removed. -Wrong return value for nativeSetBounds() was changed from long to void. AWTSurfaceLayers.m: -layer.bounds was replaced by layer.frame, because layer.bounds doesn't honour x and y position of the layer. -Wrong position inversion was removed. Also related fields were marked as volatile, if they were used in the different threads + javadoc cleanup. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172187 Webrev can be found at: http://cr.openjdk.java.net/~serb/7172187/webrev.00 -- Best regards, Sergey.
AWT Dev hg: jdk8/awt/jdk: 7172187: [macosx] JAWT native CALayer not positioned over Canvas
Changeset: 65d874d16d59 Author:serb Date: 2012-08-15 15:02 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/65d874d16d59 7172187: [macosx] JAWT native CALayer not positioned over Canvas Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/PlatformComponent.java ! src/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java ! src/macosx/native/sun/awt/AWTSurfaceLayers.m
Re: AWT Dev [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression)
Does anybody has a chance to review it? Thanks. 13.08.2012 19:26, Sergey Bylokhov wrote: Thanks Leonid. Does anybody has a chance to review it? 08.08.2012 10:20, Leonid Romanov wrote: Looks reasonable. -Original Message- From: Sergey Bylokhov [mailto:sergey.bylok...@oracle.com] Sent: Tuesday, August 07, 2012 3:40 PM To: Leonid Romanov; Mike Swingler; awt-dev@openjdk.java.net; macosx-port-...@openjdk.java.net Subject: [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 [8] Review request for 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941)
Hi,Anthony. I guess that getMinimumSize() in the setSizeConstraints should be wrapped with isMinimumSizeSet like it was in LWWindowsPeer, same for getMaximumSize() 21.08.2012 18:35, Anthony Petrov wrote: Hi Artem and Sergey, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7160609 at: http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.0/ Since OpenGL fails to create a square texture of size GL_MAX_TEXTURE_SIZE, we use the total screen bounds to limit possible window sizes on the Mac. Note that this behavior is consistent with the constraints imposed by the native OS on MS Windows, so this mustn't look like a Mac-only JDK limitation. -- best regards, Anthony -- Best regards, Sergey.
Re: AWT Dev [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression)
There are no volunteers? 20.08.2012 13:55, Sergey Bylokhov wrote: Does anybody has a chance to review it? Thanks. 13.08.2012 19:26, Sergey Bylokhov wrote: Thanks Leonid. Does anybody has a chance to review it? 08.08.2012 10:20, Leonid Romanov wrote: Looks reasonable. -Original Message- From: Sergey Bylokhov [mailto:sergey.bylok...@oracle.com] Sent: Tuesday, August 07, 2012 3:40 PM To: Leonid Romanov; Mike Swingler; awt-dev@openjdk.java.net; macosx-port-...@openjdk.java.net Subject: [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 [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
Hi, Alexander. So NSTrackingCursorUpdate option is not necessary? 27.08.2012 15:29, Alexander Scherbatiy wrote: On 8/25/2012 12:49 AM, Sergey Bylokhov wrote: Hi Alexander. In the fix NSTrackingArea has NSTrackingCursorUpdate option but i did not see cursorUpdate: method. Probably we can get some useful information from it? Now all necessary information about the cursor updating is tracked in the resetCursorRects method according to the Mouse-Tracking and Cursor-Update Events doc: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/MouseTrackingEvents/MouseTrackingEvents.html I tried to add the cursorUpdate method and in the case when a Frame is pro-grammatically moved out of the mouse cursor this method is not invoked (probably as expected). It means that the cursorUpdate method can't be used for the mouse exit event generation in this case. Such behavior is checked by the test: test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java Thanks, Alexandr. 24.08.2012 17:53, Alexander Scherbatiy пишет: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ The comments are below: On 8/23/2012 4:51 PM, Anthony Petrov wrote: Hi Alexandr, 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate through app's windows only once and send both Exited and Entered events where needed? Now, when we do not care about the order of the mouse enter/exit events generation it is possible to do. I have updated the code. 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no longer requires a window pointer as an argument. Fixed. 3. Here's a major concern: the LWWindowPeer (and other LW* classes) should never import C* classes. Instead you should've added a new method to the PlatformWindow interface, and used it from LWWindowPeer. The CPlatformWindow should've implemented this method, and called an appropriate native method from there. In this case, however, you actually need a static method, so it'd better be part of the LWToolkit interface, and implemented in the LWCToolkit class instead. I see. It seems that the getTopmostWindowUnderMouse method implementation is different for the CPlatformWindow and for the CPlatformEmbeddedFrame. So I added the getTopmostPlatformWindowUnderMouse method to the PlatformWindow interface. Thanks, Alexandr. -- best regards, Anthony On 08/23/12 15:40, Alexander Scherbatiy wrote: Could someone review the fix? Thanks, Alexandr. On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ The comments are below: On 8/7/2012 6:47 PM, Mike Swingler wrote: 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. fixed. 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 tried it. The result that I got is that a dragging mouse from one window to another does not generate mouse enter/exit events on the second window in case when tracking rect is used and the acceptsMouseMovedEvents flag is always set to YES. 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? Hi, Alexander. Probably all this stuff can be simplified? Can you try to change TrackingRect to TrackingArea with appropriate flags like NSTrackingEnabledDuringMouseDrag etc. I changed the TrackingRect to TrackingArea in the updated fix. It now generates the mouse enter/exit events on the second window during drag. So it is not necessary to generates such events from our side. The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit events for component in case when a mouse is dragged from one window to another. Where the second window contains it's own components and the only way to know about tracking over them are drag events which receives the first window. I think that the LWWindowPeer class code can be simplified if we assume that window mouse enter/exit events are always come to the current window. So the component mouse enter/exit events can be tracked only in the current or topmost window. For this case I separated the global lastCommonMouseEventPeer which is necessary for the cursor manager and the local lastMouseEventPeer. According to the specification: The proper order of mouse
AWT Dev Objective-C and jcheck
Hi Everybody. Looks like on the server we still use jcheck without fix for Objective-C files? Does anybody know how to apply the fix to jdk8? (see attachment) [jdk] pulling from http://hg.openjdk.java.net/jdk8/awt/jdk searching for changes adding changesets adding manifests adding file changes added 1 changesets with 10 changes to 10 files [jcheck 25e85a608db1 2011-07-08 09:19 -0700] Changeset: 5305:0fad89bd606b Author:alexsch Date: 2012-05-02 17:54 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side Reviewed-by: anthony, leonidr src/macosx/native/sun/awt/AWTView.m:84: Trailing whitespace src/macosx/native/sun/awt/AWTWindow.m:173: Trailing whitespace transaction abort! rollback completed skipped: pretxnchangegroup.jcheck hook failed 02.05.2012 17:53, alexandr.scherba...@oracle.com wrote Changeset: 0fad89bd606b Author:alexsch Date: 2012-05-02 17:54 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0fad89bd606b 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side Reviewed-by: anthony, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTView.h ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java + test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java + test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java ! test/java/awt/regtesthelpers/Util.java ---BeginMessage--- Folks, The 'official' copy of jcheck is not scanning .m or .mm files for whitespace violations. I use a local copy of the latest jcheck so I don't have to be on VPN all the time, and I modified the script to look at .m files as well. Two change sets just arrived with trailing whitespace. From what I have been told about mercurial and the way jcheck works, fixing this is going to be more than a simple script change because jcheck looks at each changeset as they are applied to your local workspace. I think I can work around this by relaxing the pretxnchangegroup.jcheck but we really should investigate this soon. The jcheck script fix is very easy. Change line 142 to: normext_re = re.compile(.*\.(java|c|h|cpp|hpp|m|mm)$) -- Scott K. Scott Kovatch scott.kova...@oracle.com Santa Clara/Pleasanton, CA ---End Message---
