From Sergey.Bylokhov at oracle.com Mon Sep 3 03:31:03 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 03 Sep 2012 14:31:03 +0400 Subject: [7u8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503DE7F8.2000401@oracle.com> References: <503CC029.20302@oracle.com> <503CF3E1.3040308@oracle.com> <503DE7F8.2000401@oracle.com> Message-ID: <504486E7.9070801@oracle.com> Hi, Alexander. Fix looks good. 29.08.2012 13:59, Alexander Scherbatiy wrote: > > Could you review the updated fix for the JDK 7u8 where the failed test > is removed: > http://cr.openjdk.java.net/~alexsch/7171045/webrev7.02/ > > On 8/28/2012 8:37 PM, Anthony Petrov wrote: >> Hi Alexander, >> >> 1. Does the >> closed/javax/swing/plaf/basic/BasicToolBarUI/4331392/bug4331392.java >> test (mentioned in 7154048) pass with this fix? > Yes, the test passes. The fix reverted back changes after the > 7154048 fix. > http://cr.openjdk.java.net/~alexsch/7154048/webrev7.00/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html >> >> 2. What is the plan for DragWindowTest.java? We should either remove >> it with this fix, or file a CR and remove '@' from the '@run' jtreg >> tag so that it wouldn't fail for the time being. > I removed the failed DragWindowTest.java from the JDK 7u > repository in the updated fix. But it still presents in the JDK 8 > repository and passes with the fixed 7154048 and 7171045 issues. > > Thanks, > Alexandr. > >> >> -- >> best regards, >> Anthony >> >> On 8/28/2012 4:57 PM, Alexander Scherbatiy wrote: >>> Hello, >>> >>> Please review the fix for the JDK 7u8: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev7.00/ >>> >>> 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 disabling component mouse enter/exit events generation during >>> drag leads that it does not work in the case where a mouse is >>> dragged over the current window. >>> >>> The full fix that checks that a current window is a topmost window >>> under mouse requires some changes (using tracking area instead of >>> tracking rectangle and so on) is a quite complicated and it seems >>> that it is risky to include it to the JDK 7u8. >>> >>> Current fix just changes the condition for the component mouse >>> enter/exit events generation to the initial state how it was before >>> the 7154048 fix. >>> >>> This allows to generate components mouse enter/exit events, but the >>> following test will fail: >>> java/awt/Mouse/EnterExitEvents/DragWindowTest.java >>> However this test did not work before the 7154048 fix so it is not a >>> regression. >>> >>> >>> Thanks, >>> Alexandr. >>> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Sep 4 04:56:19 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 04 Sep 2012 15:56:19 +0400 Subject: [8] Request for review: 7124523 [macosx] b216: Mising part of applet UI Message-ID: <5045EC63.3070700@oracle.com> Hello, This is direct forward port from jdk 7u4 to jdk8. The size of components is a bit bigger and one of the buttons simply doesn't fit into the window. Default size of the demo window should be increased. Two demos affected. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124523 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124523/webrev.00 Technical review for jdk7u4: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003508.html -- Best regards, Sergey. From marco.dinacci at gmail.com Tue Sep 4 06:42:53 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Tue, 4 Sep 2012 14:42:53 +0100 Subject: [PATCH] 7160951: ActionListener called twice for JMenuItem using ScreenMenuBar Message-ID: Hello, The following patch, based on changeset 0b236cc20500 (jdk7u8-b05 tag), fixes http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160951 The patch checks whether the NSEvent received in the NSMenuItem callback coincides with the NSMenuItem accelerator. If it does, it doesn't call the Java callback. # HG changeset patch # User Marco Dinacci # Date 1346764262 -3600 # Node ID c451e0ad537c9856ccc7be5488360070ba657142 # Parent 57d81e01a61fb8be46ef792dce63b0aa2a88992d Fix bug #7160951 diff --git a/src/macosx/native/sun/awt/CMenuItem.m b/src/macosx/native/sun/awt/CMenuItem.m --- a/src/macosx/native/sun/awt/CMenuItem.m +++ b/src/macosx/native/sun/awt/CMenuItem.m @@ -82,22 +82,36 @@ JNF_COCOA_ENTER(env); } else { static JNF_CLASS_CACHE(jc_CMenuItem, "sun/lwawt/macosx/CMenuItem"); static JNF_MEMBER_CACHE(jm_handleAction, jc_CMenuItem, "handleAction", "(JI)V"); // AWT_THREADING Safe (event) NSEvent *currEvent = [[NSApplication sharedApplication] currentEvent]; NSUInteger modifiers = [currEvent modifierFlags]; jint javaModifiers = 0; - if ((modifiers & NSCommandKeyMask) != 0) javaModifiers |= java_awt_Event_META_MASK; - if ((modifiers & NSShiftKeyMask) != 0) javaModifiers |= java_awt_Event_SHIFT_MASK; - if ((modifiers & NSControlKeyMask) != 0) javaModifiers |= java_awt_Event_CTRL_MASK; - if ((modifiers & NSAlternateKeyMask) != 0) javaModifiers |= java_awt_Event_ALT_MASK; + NSEventType type = [currEvent type]; + if (type == NSKeyDown) { + NSString *menuKey = [sender keyEquivalent]; + NSString *eventKey = [currEvent characters]; + + if (![menuKey isEqualToString:eventKey]) { + // Only send the event if the NSEvent characters do not + // coincides with the NSMenuItem keyEquivalent. - JNFCallVoidMethod(env, fPeer, jm_handleAction, UTC(currEvent), javaModifiers); // AWT_THREADING Safe (event) + if ((modifiers & NSCommandKeyMask) != 0) javaModifiers |= java_awt_Event_META_MASK; + if ((modifiers & NSShiftKeyMask) != 0) javaModifiers |= java_awt_Event_SHIFT_MASK; + if ((modifiers & NSControlKeyMask) != 0) javaModifiers |= java_awt_Event_CTRL_MASK; + if ((modifiers & NSAlternateKeyMask) != 0) javaModifiers |= java_awt_Event_ALT_MASK; + + JNFCallVoidMethod(env, fPeer, jm_handleAction, UTC(currEvent), javaModifiers); // AWT_THREADING Safe (event) + } + } else { + JNFCallVoidMethod(env, fPeer, jm_handleAction, UTC(currEvent), javaModifiers); // AWT_THREADING Safe (event) + } + } JNF_COCOA_EXIT(env); } - (void) setJavaLabel:(NSString *)theLabel shortcut:(NSString *)theKeyEquivalent modifierMask:(jint)modifiers { AWT_ASSERT_NOT_APPKIT_THREAD; NSUInteger modifierMask = 0; exporting patch: Best, Marco From marco.dinacci at gmail.com Tue Sep 4 07:01:53 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Tue, 4 Sep 2012 15:01:53 +0100 Subject: [PATCH] 7186371: Main menu shortcuts not displayed (7u6 regression) Message-ID: Hello, the attached patch provides a workaround for bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 I discussed about this problem a while ago but my suggested change was causing bug #7160951. I'm reposting now this patch since I also proposed a patch to fix #7160951. The change consists simply in calling setAccelerator after calling setLabel since setLabel(String) resets all informations about the keyboard accelerator. --- a/src/macosx/classes/com/apple/laf/ScreenMenuItem.java Mon Jun 18 11:31:18 2012 +0100 +++ b/src/macosx/classes/com/apple/laf/ScreenMenuItem.java Mon Jun 18 16:56:31 2012 +0100 @@ -56,24 +56,23 @@ class ScreenMenuItem extends MenuItem im fMenuItem.addComponentListener(this); fListener = new ScreenMenuPropertyListener(this); fMenuItem.addPropertyChangeListener(fListener); addActionListener(this); setEnabled(fMenuItem.isEnabled()); - // can't setState or setAccelerator or setIcon till we have a peer - setAccelerator(fMenuItem.getAccelerator()); - final String label = fMenuItem.getText(); if (label != null) { setLabel(label); } + setAccelerator(fMenuItem.getAccelerator()); + final Icon icon = fMenuItem.getIcon(); if (icon != null) { this.setIcon(icon); } final String tooltipText = fMenuItem.getToolTipText(); if (tooltipText != null) { this.setToolTipText(tooltipText); Best, Marco From Sergey.Bylokhov at oracle.com Tue Sep 4 07:10:04 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 04 Sep 2012 18:10:04 +0400 Subject: [PATCH] 7186371: Main menu shortcuts not displayed (7u6 regression) In-Reply-To: References: Message-ID: <50460BBC.8010903@oracle.com> Hi, Marco. This issue was fixed in jdk8 and will be backported to 7u8 a little bit later. http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f54660c18774 04.09.2012 18:01, Marco Dinacci wrote: > Hello, > > the attached patch provides a workaround for bug > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 > > I discussed about this problem a while ago but my suggested change was > causing bug #7160951. > I'm reposting now this patch since I also proposed a patch to fix #7160951. > > The change consists simply in calling setAccelerator after calling > setLabel since setLabel(String) resets all informations about the > keyboard accelerator. > > --- a/src/macosx/classes/com/apple/laf/ScreenMenuItem.java Mon Jun 18 > 11:31:18 2012 +0100 > +++ b/src/macosx/classes/com/apple/laf/ScreenMenuItem.java Mon Jun 18 > 16:56:31 2012 +0100 > @@ -56,24 +56,23 @@ class ScreenMenuItem extends MenuItem im > > fMenuItem.addComponentListener(this); > fListener = new ScreenMenuPropertyListener(this); > fMenuItem.addPropertyChangeListener(fListener); > addActionListener(this); > > setEnabled(fMenuItem.isEnabled()); > > - // can't setState or setAccelerator or setIcon till we have a peer > - setAccelerator(fMenuItem.getAccelerator()); > - > final String label = fMenuItem.getText(); > if (label != null) { > setLabel(label); > } > > + setAccelerator(fMenuItem.getAccelerator()); > + > final Icon icon = fMenuItem.getIcon(); > if (icon != null) { > this.setIcon(icon); > } > > final String tooltipText = fMenuItem.getToolTipText(); > if (tooltipText != null) { > this.setToolTipText(tooltipText); > > > Best, > Marco -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Sep 4 07:11:31 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 04 Sep 2012 18:11:31 +0400 Subject: [PATCH] 7160951: ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: References: Message-ID: <50460C13.7070102@oracle.com> Hi, Marco. After the changes, shortcuts in the simple awt menu(not swing) continue to work? Thanks. 04.09.2012 17:42, Marco Dinacci wrote: > Hello, > > The following patch, based on changeset 0b236cc20500 (jdk7u8-b05 tag), > fixes http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160951 > > The patch checks whether the NSEvent received in the NSMenuItem > callback coincides with the NSMenuItem accelerator. If it does, it > doesn't call the Java callback. > > # HG changeset patch > # User Marco Dinacci > # Date 1346764262 -3600 > # Node ID c451e0ad537c9856ccc7be5488360070ba657142 > # Parent 57d81e01a61fb8be46ef792dce63b0aa2a88992d > Fix bug #7160951 > > diff --git a/src/macosx/native/sun/awt/CMenuItem.m > b/src/macosx/native/sun/awt/CMenuItem.m > --- a/src/macosx/native/sun/awt/CMenuItem.m > +++ b/src/macosx/native/sun/awt/CMenuItem.m > @@ -82,22 +82,36 @@ JNF_COCOA_ENTER(env); > } else { > static JNF_CLASS_CACHE(jc_CMenuItem, "sun/lwawt/macosx/CMenuItem"); > static JNF_MEMBER_CACHE(jm_handleAction, jc_CMenuItem, > "handleAction", "(JI)V"); // AWT_THREADING Safe (event) > > NSEvent *currEvent = [[NSApplication sharedApplication] currentEvent]; > NSUInteger modifiers = [currEvent modifierFlags]; > jint javaModifiers = 0; > > - if ((modifiers & NSCommandKeyMask) != 0) javaModifiers |= > java_awt_Event_META_MASK; > - if ((modifiers & NSShiftKeyMask) != 0) javaModifiers |= > java_awt_Event_SHIFT_MASK; > - if ((modifiers & NSControlKeyMask) != 0) javaModifiers |= > java_awt_Event_CTRL_MASK; > - if ((modifiers & NSAlternateKeyMask) != 0) javaModifiers |= > java_awt_Event_ALT_MASK; > + NSEventType type = [currEvent type]; > + if (type == NSKeyDown) { > + NSString *menuKey = [sender keyEquivalent]; > + NSString *eventKey = [currEvent characters]; > + > + if (![menuKey isEqualToString:eventKey]) { > + // Only send the event if the NSEvent characters do not > + // coincides with the NSMenuItem keyEquivalent. > > - JNFCallVoidMethod(env, fPeer, jm_handleAction, > UTC(currEvent), javaModifiers); // AWT_THREADING Safe (event) > + if ((modifiers & NSCommandKeyMask) != 0) > javaModifiers |= java_awt_Event_META_MASK; > + if ((modifiers & NSShiftKeyMask) != 0) > javaModifiers |= java_awt_Event_SHIFT_MASK; > + if ((modifiers & NSControlKeyMask) != 0) > javaModifiers |= java_awt_Event_CTRL_MASK; > + if ((modifiers & NSAlternateKeyMask) != 0) > javaModifiers |= java_awt_Event_ALT_MASK; > + > + JNFCallVoidMethod(env, fPeer, jm_handleAction, > UTC(currEvent), javaModifiers); // AWT_THREADING Safe (event) > + } > + } else { > + JNFCallVoidMethod(env, fPeer, jm_handleAction, > UTC(currEvent), javaModifiers); // AWT_THREADING Safe (event) > + } > + > } > JNF_COCOA_EXIT(env); > } > > - (void) setJavaLabel:(NSString *)theLabel shortcut:(NSString > *)theKeyEquivalent modifierMask:(jint)modifiers { > AWT_ASSERT_NOT_APPKIT_THREAD; > > NSUInteger modifierMask = 0; > exporting patch: > > > > Best, > Marco ` -- Best regards, Sergey. From marco.dinacci at gmail.com Tue Sep 4 07:18:03 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Tue, 4 Sep 2012 15:18:03 +0100 Subject: [PATCH] 7160951: ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: <50460C13.7070102@oracle.com> References: <50460C13.7070102@oracle.com> Message-ID: Hi Sergey, > After the changes, shortcuts in the simple awt menu(not swing) continue to > work? I don't know if you're referring to some particular example, but this test case using only AWT works well: import java.awt.*; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.awt.event.KeyEvent; public class TestAWT extends Frame { public TestAWT() { MenuBar menuBar = new MenuBar(); Menu fileMenu = new Menu("Test Menu"); MenuShortcut shortcut = new MenuShortcut(KeyEvent.VK_L, false); MenuItem openItem = new MenuItem("Test Item", shortcut); openItem.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { System.out.println("ActionListener was called"); } }); fileMenu.add(openItem); menuBar.add(fileMenu); setMenuBar(menuBar); pack(); setVisible(true); } public static void main(String[] args) { System.setProperty("apple.laf.useScreenMenuBar", "true"); new TestAWT(); } } Best, Marco From marco.dinacci at gmail.com Tue Sep 4 07:20:22 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Tue, 4 Sep 2012 15:20:22 +0100 Subject: [PATCH] 7186371: Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <50460BBC.8010903@oracle.com> References: <50460BBC.8010903@oracle.com> Message-ID: Hi, > This issue was fixed in jdk8 and will be backported to 7u8 a little bit > later. > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f54660c18774 that's good news, thanks ! Best, Marco From scott.kovatch at oracle.com Tue Sep 4 08:16:03 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 4 Sep 2012 08:16:03 -0700 Subject: Review: Remove private API from graphics code In-Reply-To: <5041077A.7080002@oracle.com> References: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> <5040FF7B.4030106@oracle.com> <5041077A.7080002@oracle.com> Message-ID: I posted a new webrev at http://cr.openjdk.java.net/~skovatch/7187834/webrev.01/ In ImageSurfaceData, it looks like we are trying to get back to a pure CTM (i.e., no transform of any kind applied.) before we draw the image. We have already saved the state, but saving the state doesn't reset it. That's why there are extra gyrations to invert and concat the inversion. In QuartzRenderer.m the information you found applies, so I'm just using that now. These changes fix the printing bugs in Java2Demo that I saw with the first webrev. -- Scott On Aug 31, 2012, at 11:50 AM, Phil Race wrote: > The recommendation is to restore the graphics state rather than inverting :- > > https://developer.apple.com/library/mac/#documentation/graphicsimaging/conceptual/drawingwithquartz2d/dq_affine/dq_affine.html > > "Quartz also provides an affine transform function that inverts a matrix, |CGAffineTransformInvert|. Inversion is generally used to provide reverse transformation of points within transformed objects. Inversion can be useful when you need to recover a value that has been transformed by a matrix: Invert the matrix, and multiply the value by the inverted matrix, and the result is the original value. You usually don?t need to invert transforms because you can reverse the effects of transforming the CTM by saving and restoring the graphics state." > > -phil. > > On 8/31/2012 11:16 AM, Phil Race wrote: >> Scott, >> >> These files were added by Bino to support printing. Quartz isn't used >> except for printing in JDK 7, so as I understand it, testing on-screen in >> Java2Demo should not exercise this code. I'm surprised that you saw >> it being exercised. Did you do any printing testing ? >> >> The matrix inversion seems unlikely to be applied to any non-invertible >> matrices, so that's fine, but I wonder if you have lost precision here >> due to floating point inaccuracies ? >> >> If you originally had a simple scale or identity, rotated it, and then >> applied the inverse to unrotate it, do you really end up with exactly >> the same results. The more you do this the more inaccuracies creep in, >> which may be part of the reason for the original approach. >> I find it a little hard to believe that there isn't a direct public way to >> restore a transform. >> >> The changes for mountain lion are safe for snow leopard I presume? >> I believe the builds still happen on snow leopard. >> >> Also this should have been sent to 2d-dev, not awt-dev. >> These files, APIs, and printing are all 2D, not awt. >> >> -phil. >> >> I am not sure why they are not used but it >> On 8/31/2012 10:45 AM, Scott Kovatch wrote: >>> http://cr.openjdk.java.net/~skovatch/7187834/webrev.00/ >>> >>> This is based on the patch submitted by Marco Dinacci. I had to modify it a bit to get it to compile against 7u-dev, but nothing major. >>> >>> The changes in ImageSurfaceData.h were needed as a result of my use of Xcode 4.4.1 on Mountain Lion. >>> >>> I ran the Java2Demo and don't see any problems. I paid close attention to the Images tab, since it looks like this code is heavily used by it. >>> >>> -- Scott K. >>> >>> ---------------------------------------- >>> Scott Kovatch >>> scott.kovatch at oracle.com >>> Santa Clara/Pleasanton, CA >>> >>> >> > From scott.kovatch at oracle.com Tue Sep 4 08:27:59 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 4 Sep 2012 08:27:59 -0700 Subject: Review: Remove private API from graphics code In-Reply-To: <5041077A.7080002@oracle.com> References: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> <5040FF7B.4030106@oracle.com> <5041077A.7080002@oracle.com> Message-ID: <1F1FBA0C-8809-4439-8774-20DB5B6018E3@oracle.com> (resending, now that I'm on 2d-dev.) I posted a new webrev at http://cr.openjdk.java.net/~skovatch/7187834/webrev.01/ In ImageSurfaceData, it looks like we are trying to get back to a pure CTM (i.e., no transform of any kind applied.) before we draw the image. We have already saved the state, but saving the state doesn't reset it. That's why there are extra gyrations to invert and concat the inversion. In QuartzRenderer.m the information you found applies, so I'm just using that now. These changes fix the printing bugs in Java2Demo that I saw with the first webrev. -- Scott On Aug 31, 2012, at 11:50 AM, Phil Race wrote: > The recommendation is to restore the graphics state rather than inverting :- > > https://developer.apple.com/library/mac/#documentation/graphicsimaging/conceptual/drawingwithquartz2d/dq_affine/dq_affine.html > > "Quartz also provides an affine transform function that inverts a matrix, |CGAffineTransformInvert|. Inversion is generally used to provide reverse transformation of points within transformed objects. Inversion can be useful when you need to recover a value that has been transformed by a matrix: Invert the matrix, and multiply the value by the inverted matrix, and the result is the original value. You usually don?t need to invert transforms because you can reverse the effects of transforming the CTM by saving and restoring the graphics state." > > -phil. > > On 8/31/2012 11:16 AM, Phil Race wrote: >> Scott, >> >> These files were added by Bino to support printing. Quartz isn't used >> except for printing in JDK 7, so as I understand it, testing on-screen in >> Java2Demo should not exercise this code. I'm surprised that you saw >> it being exercised. Did you do any printing testing ? >> >> The matrix inversion seems unlikely to be applied to any non-invertible >> matrices, so that's fine, but I wonder if you have lost precision here >> due to floating point inaccuracies ? >> >> If you originally had a simple scale or identity, rotated it, and then >> applied the inverse to unrotate it, do you really end up with exactly >> the same results. The more you do this the more inaccuracies creep in, >> which may be part of the reason for the original approach. >> I find it a little hard to believe that there isn't a direct public way to >> restore a transform. >> >> The changes for mountain lion are safe for snow leopard I presume? >> I believe the builds still happen on snow leopard. >> >> Also this should have been sent to 2d-dev, not awt-dev. >> These files, APIs, and printing are all 2D, not awt. >> >> -phil. >> >> I am not sure why they are not used but it >> On 8/31/2012 10:45 AM, Scott Kovatch wrote: >>> http://cr.openjdk.java.net/~skovatch/7187834/webrev.00/ >>> >>> This is based on the patch submitted by Marco Dinacci. I had to modify it a bit to get it to compile against 7u-dev, but nothing major. >>> >>> The changes in ImageSurfaceData.h were needed as a result of my use of Xcode 4.4.1 on Mountain Lion. >>> >>> I ran the Java2Demo and don't see any problems. I paid close attention to the Images tab, since it looks like this code is heavily used by it. >>> >>> -- Scott K. >>> >>> ---------------------------------------- >>> Scott Kovatch >>> scott.kovatch at oracle.com >>> Santa Clara/Pleasanton, CA >>> >>> >> > From private at claudio.ch Tue Sep 4 09:49:16 2012 From: private at claudio.ch (Claudio Nieder) Date: Tue, 4 Sep 2012 18:49:16 +0200 Subject: Path for hsdis Makefile Message-ID: <219C3DF2-44EE-4C56-99AD-628940D99225@claudio.ch> Hi, for my personal use I modified jdk7u/hotspot/src/share/tools/hsdis/Makefile to support OS X. I herby put the below patch into the public domain for anyone to use as (s)he wants. --- Makefile.orig 2012-09-04 18:02:08.000000000 +0200 +++ Makefile 2012-09-04 18:40:26.000000000 +0200 @@ -52,6 +52,18 @@ OUTFLAGS += -o $@ LIB_EXT = .so else +## OS = OSX ## +ifeq ($(OS),Darwin) +OS = Darwin +CC = gcc +ARCH = amd64 +CFLAGS += -m64 +DLDFLAGS += -dynamiclib +DLDFLAGS += -lz +LDFLAGS += -ldl +OUTFLAGS += -o $@ +LIB_EXT = .dylib +else ## OS = Linux ## ifeq ($(OS),Linux) ifneq ($(MINGW),) @@ -96,6 +108,7 @@ OUTFLAGS += /link /out:$@ LIB_EXT = .dll endif # Linux +endif # Darwin endif # SunOS LIBARCH = $(ARCH) @@ -118,7 +131,7 @@ BINUTILSDIR = $(shell cd $(BINUTILS);pwd) endif -CPPFLAGS += -I$(BINUTILSDIR)/include -I$(BINUTILS)/bfd -I$(TARGET_DIR)/bfd +CPPFLAGS += -I$(BINUTILSDIR)/include -I$(BINUTILSDIR)/bfd -I$(TARGET_DIR)/bfd CPPFLAGS += -DLIBARCH_$(LIBARCH) -DLIBARCH=\"$(LIBARCH)\" -DLIB_EXT=\"$(LIB_EXT)\" TARGET_DIR = build/$(OS)-$(JDKARCH) Please note, that the last change (BINUTILS -> BINUTILSDIR) points to a bug in the original Makefile while everything else is extension to support OSX. claudio -- Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch From philip.race at oracle.com Tue Sep 4 09:55:11 2012 From: philip.race at oracle.com (Phil Race) Date: Tue, 04 Sep 2012 09:55:11 -0700 Subject: Review: Remove private API from graphics code In-Reply-To: <1F1FBA0C-8809-4439-8774-20DB5B6018E3@oracle.com> References: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> <5040FF7B.4030106@oracle.com> <5041077A.7080002@oracle.com> <1F1FBA0C-8809-4439-8774-20DB5B6018E3@oracle.com> Message-ID: <5046326F.7010202@oracle.com> Approved. -phil. On 9/4/2012 8:27 AM, Scott Kovatch wrote: > (resending, now that I'm on 2d-dev.) > I posted a new webrev at http://cr.openjdk.java.net/~skovatch/7187834/webrev.01/ > > In ImageSurfaceData, it looks like we are trying to get back to a pure CTM (i.e., no transform of any kind applied.) before we draw the image. We have already saved the state, but saving the state doesn't reset it. That's why there are extra gyrations to invert and concat the inversion. In QuartzRenderer.m the information you found applies, so I'm just using that now. > > These changes fix the printing bugs in Java2Demo that I saw with the first webrev. > > -- Scott > > > On Aug 31, 2012, at 11:50 AM, Phil Race wrote: > >> The recommendation is to restore the graphics state rather than inverting :- >> >> https://developer.apple.com/library/mac/#documentation/graphicsimaging/conceptual/drawingwithquartz2d/dq_affine/dq_affine.html >> >> "Quartz also provides an affine transform function that inverts a matrix, |CGAffineTransformInvert|. Inversion is generally used to provide reverse transformation of points within transformed objects. Inversion can be useful when you need to recover a value that has been transformed by a matrix: Invert the matrix, and multiply the value by the inverted matrix, and the result is the original value. You usually don?t need to invert transforms because you can reverse the effects of transforming the CTM by saving and restoring the graphics state." >> >> -phil. >> >> On 8/31/2012 11:16 AM, Phil Race wrote: >>> Scott, >>> >>> These files were added by Bino to support printing. Quartz isn't used >>> except for printing in JDK 7, so as I understand it, testing on-screen in >>> Java2Demo should not exercise this code. I'm surprised that you saw >>> it being exercised. Did you do any printing testing ? >>> >>> The matrix inversion seems unlikely to be applied to any non-invertible >>> matrices, so that's fine, but I wonder if you have lost precision here >>> due to floating point inaccuracies ? >>> >>> If you originally had a simple scale or identity, rotated it, and then >>> applied the inverse to unrotate it, do you really end up with exactly >>> the same results. The more you do this the more inaccuracies creep in, >>> which may be part of the reason for the original approach. >>> I find it a little hard to believe that there isn't a direct public way to >>> restore a transform. >>> >>> The changes for mountain lion are safe for snow leopard I presume? >>> I believe the builds still happen on snow leopard. >>> >>> Also this should have been sent to 2d-dev, not awt-dev. >>> These files, APIs, and printing are all 2D, not awt. >>> >>> -phil. >>> >>> I am not sure why they are not used but it >>> On 8/31/2012 10:45 AM, Scott Kovatch wrote: >>>> http://cr.openjdk.java.net/~skovatch/7187834/webrev.00/ >>>> >>>> This is based on the patch submitted by Marco Dinacci. I had to modify it a bit to get it to compile against 7u-dev, but nothing major. >>>> >>>> The changes in ImageSurfaceData.h were needed as a result of my use of Xcode 4.4.1 on Mountain Lion. >>>> >>>> I ran the Java2Demo and don't see any problems. I paid close attention to the Images tab, since it looks like this code is heavily used by it. >>>> >>>> -- Scott K. >>>> >>>> ---------------------------------------- >>>> Scott Kovatch >>>> scott.kovatch at oracle.com >>>> Santa Clara/Pleasanton, CA >>>> >>>> From leonid.romanov at oracle.com Tue Sep 4 12:10:34 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 4 Sep 2012 23:10:34 +0400 Subject: Would it be OK to override NSView's _wantsKeyDownForEvent? Message-ID: <6FC58C1B-E874-45A5-8102-DAD01FCA898C@oracle.com> Hello, Overriding _wantsKeyDownForEvent to return YES would give us key down events for Ctrl-Tab and Ctrl-Esc (otherwise the only way to receive them is to override performKeyEquivalent). This, in turn, would allow me to simplify our code a bit. However, I'm worried whether overriding _wantsKeyDownForEvent would be considered as Private APIs usage, which we obviously want to avoid. Thanks, Leonid. From scott.kovatch at oracle.com Tue Sep 4 16:13:21 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 4 Sep 2012 16:13:21 -0700 Subject: Would it be OK to override NSView's _wantsKeyDownForEvent? In-Reply-To: <6FC58C1B-E874-45A5-8102-DAD01FCA898C@oracle.com> References: <6FC58C1B-E874-45A5-8102-DAD01FCA898C@oracle.com> Message-ID: <054240C9-77F5-469C-89D5-D0CEDD399CB8@oracle.com> On Sep 4, 2012, at 12:10 PM, Leonid Romanov wrote: > Hello, > Overriding _wantsKeyDownForEvent to return YES would give us key down events for Ctrl-Tab and Ctrl-Esc (otherwise the only way to receive them is to override performKeyEquivalent). This, in turn, would allow me to simplify our code a bit. > However, I'm worried whether overriding _wantsKeyDownForEvent would be considered as Private APIs usage, which we obviously want to avoid. The only way we'll know for sure is to submit something and see what happens. Since you want to override it, as opposed to calling it, we might be on more solid ground. The private APIs we've had to deal with so far involved explicitly calling functions in CoreGraphics. -- Scott K. From igor.nekrestyanov at oracle.com Tue Sep 4 21:14:57 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Tue, 04 Sep 2012 21:14:57 -0700 Subject: Review: Remove private API from graphics code In-Reply-To: <1F1FBA0C-8809-4439-8774-20DB5B6018E3@oracle.com> References: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> <5040FF7B.4030106@oracle.com> <5041077A.7080002@oracle.com> <1F1FBA0C-8809-4439-8774-20DB5B6018E3@oracle.com> Message-ID: <5046D1C1.7060208@oracle.com> Looks ok to me. -igor On 9/4/12 8:27 AM, Scott Kovatch wrote: > (resending, now that I'm on 2d-dev.) > I posted a new webrev at http://cr.openjdk.java.net/~skovatch/7187834/webrev.01/ > > In ImageSurfaceData, it looks like we are trying to get back to a pure CTM (i.e., no transform of any kind applied.) before we draw the image. We have already saved the state, but saving the state doesn't reset it. That's why there are extra gyrations to invert and concat the inversion. In QuartzRenderer.m the information you found applies, so I'm just using that now. > > These changes fix the printing bugs in Java2Demo that I saw with the first webrev. > > -- Scott > > > On Aug 31, 2012, at 11:50 AM, Phil Race wrote: > >> The recommendation is to restore the graphics state rather than inverting :- >> >> https://developer.apple.com/library/mac/#documentation/graphicsimaging/conceptual/drawingwithquartz2d/dq_affine/dq_affine.html >> >> "Quartz also provides an affine transform function that inverts a matrix, |CGAffineTransformInvert|. Inversion is generally used to provide reverse transformation of points within transformed objects. Inversion can be useful when you need to recover a value that has been transformed by a matrix: Invert the matrix, and multiply the value by the inverted matrix, and the result is the original value. You usually don?t need to invert transforms because you can reverse the effects of transforming the CTM by saving and restoring the graphics state." >> >> -phil. >> >> On 8/31/2012 11:16 AM, Phil Race wrote: >>> Scott, >>> >>> These files were added by Bino to support printing. Quartz isn't used >>> except for printing in JDK 7, so as I understand it, testing on-screen in >>> Java2Demo should not exercise this code. I'm surprised that you saw >>> it being exercised. Did you do any printing testing ? >>> >>> The matrix inversion seems unlikely to be applied to any non-invertible >>> matrices, so that's fine, but I wonder if you have lost precision here >>> due to floating point inaccuracies ? >>> >>> If you originally had a simple scale or identity, rotated it, and then >>> applied the inverse to unrotate it, do you really end up with exactly >>> the same results. The more you do this the more inaccuracies creep in, >>> which may be part of the reason for the original approach. >>> I find it a little hard to believe that there isn't a direct public way to >>> restore a transform. >>> >>> The changes for mountain lion are safe for snow leopard I presume? >>> I believe the builds still happen on snow leopard. >>> >>> Also this should have been sent to 2d-dev, not awt-dev. >>> These files, APIs, and printing are all 2D, not awt. >>> >>> -phil. >>> >>> I am not sure why they are not used but it >>> On 8/31/2012 10:45 AM, Scott Kovatch wrote: >>>> http://cr.openjdk.java.net/~skovatch/7187834/webrev.00/ >>>> >>>> This is based on the patch submitted by Marco Dinacci. I had to modify it a bit to get it to compile against 7u-dev, but nothing major. >>>> >>>> The changes in ImageSurfaceData.h were needed as a result of my use of Xcode 4.4.1 on Mountain Lion. >>>> >>>> I ran the Java2Demo and don't see any problems. I paid close attention to the Images tab, since it looks like this code is heavily used by it. >>>> >>>> -- Scott K. >>>> >>>> ---------------------------------------- >>>> Scott Kovatch >>>> scott.kovatch at oracle.com >>>> Santa Clara/Pleasanton, CA >>>> >>>> From Sergey.Bylokhov at oracle.com Wed Sep 5 03:03:48 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 05 Sep 2012 14:03:48 +0400 Subject: [7u10] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) Message-ID: <50472384.2000800@oracle.com> Hi Everyone, Please review the fix. This is backport from jdk8 to 7u10 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 jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f54660c18774 -- Best regards, Sergey. From leonid.romanov at oracle.com Tue Sep 4 23:07:38 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 5 Sep 2012 10:07:38 +0400 Subject: [7u10] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <50472384.2000800@oracle.com> References: <50472384.2000800@oracle.com> Message-ID: <000001cd8b2c$c1f28210$45d78630$@oracle.com> Looks OK. > -----Original Message----- > From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] > Sent: Wednesday, September 05, 2012 2:04 PM > To: Leonid Romanov; Artem Ananiev > Cc: awt-dev at openjdk.java.net; macosx-port-dev at openjdk.java.net > Subject: [7u10] Review request for 7186371: [macosx] Main menu shortcuts > not displayed (7u6 regression) > > Hi Everyone, > Please review the fix. This is backport from jdk8 to 7u10 > 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 > jdk8 changeset: > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f54660c18774 > > -- > Best regards, Sergey. From alexandr.scherbatiy at oracle.com Wed Sep 5 04:14:35 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 05 Sep 2012 15:14:35 +0400 Subject: [8] Request for review: 7124523 [macosx] b216: Mising part of applet UI In-Reply-To: <5045EC63.3070700@oracle.com> References: <5045EC63.3070700@oracle.com> Message-ID: <5047341B.1080009@oracle.com> The fix looks fine to me. Thanks, Alexandr. On 9/4/2012 3:56 PM, Sergey Bylokhov wrote: > Hello, > This is direct forward port from jdk 7u4 to jdk8. > The size of components is a bit bigger and one of the buttons simply > doesn't fit into the window. > Default size of the demo window should be increased. Two demos affected. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124523 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124523/webrev.00 > Technical review for jdk7u4: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003508.html > > From leonid.romanov at oracle.com Wed Sep 5 06:11:36 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 5 Sep 2012 17:11:36 +0400 Subject: Would it be OK to override NSView's _wantsKeyDownForEvent? In-Reply-To: <054240C9-77F5-469C-89D5-D0CEDD399CB8@oracle.com> References: <6FC58C1B-E874-45A5-8102-DAD01FCA898C@oracle.com> <054240C9-77F5-469C-89D5-D0CEDD399CB8@oracle.com> Message-ID: I see? I hoped there would be some Apple provided tool to check it locally. I don't want to put a burden of finding out whether Apple considers it to be a private API to JDK users. On Sep 5, 2012, at 3:13 AM, Scott Kovatch wrote: > > On Sep 4, 2012, at 12:10 PM, Leonid Romanov wrote: > >> Hello, >> Overriding _wantsKeyDownForEvent to return YES would give us key down events for Ctrl-Tab and Ctrl-Esc (otherwise the only way to receive them is to override performKeyEquivalent). This, in turn, would allow me to simplify our code a bit. >> However, I'm worried whether overriding _wantsKeyDownForEvent would be considered as Private APIs usage, which we obviously want to avoid. > > The only way we'll know for sure is to submit something and see what happens. > > Since you want to override it, as opposed to calling it, we might be on more solid ground. The private APIs we've had to deal with so far involved explicitly calling functions in CoreGraphics. > > -- Scott K. > > From leonid.romanov at oracle.com Wed Sep 5 10:05:47 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 5 Sep 2012 21:05:47 +0400 Subject: [PATCH] 7160951: ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: <50460C13.7070102@oracle.com> References: <50460C13.7070102@oracle.com> Message-ID: <3D7B6B3E-970A-4F6E-9A79-23C1E681D4B8@oracle.com> Hi, Marco Why do we need [menuKey isEqualToString:eventKey] check? If Cocoa has called our action callback and the type of the event which triggered that call is NSKeyDown, doesn't it mean we can be sure that a shortcut has been pressed? On Sep 4, 2012, at 6:11 PM, Sergey Bylokhov wrote: > Hi, Marco. > After the changes, shortcuts in the simple awt menu(not swing) continue to work? > > Thanks. > > 04.09.2012 17:42, Marco Dinacci wrote: >> Hello, >> >> The following patch, based on changeset 0b236cc20500 (jdk7u8-b05 tag), >> fixes http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160951 >> >> The patch checks whether the NSEvent received in the NSMenuItem >> callback coincides with the NSMenuItem accelerator. If it does, it >> doesn't call the Java callback. >> >> # HG changeset patch >> # User Marco Dinacci >> # Date 1346764262 -3600 >> # Node ID c451e0ad537c9856ccc7be5488360070ba657142 >> # Parent 57d81e01a61fb8be46ef792dce63b0aa2a88992d >> Fix bug #7160951 >> >> diff --git a/src/macosx/native/sun/awt/CMenuItem.m >> b/src/macosx/native/sun/awt/CMenuItem.m >> --- a/src/macosx/native/sun/awt/CMenuItem.m >> +++ b/src/macosx/native/sun/awt/CMenuItem.m >> @@ -82,22 +82,36 @@ JNF_COCOA_ENTER(env); >> } else { >> static JNF_CLASS_CACHE(jc_CMenuItem, "sun/lwawt/macosx/CMenuItem"); >> static JNF_MEMBER_CACHE(jm_handleAction, jc_CMenuItem, >> "handleAction", "(JI)V"); // AWT_THREADING Safe (event) >> >> NSEvent *currEvent = [[NSApplication sharedApplication] currentEvent]; >> NSUInteger modifiers = [currEvent modifierFlags]; >> jint javaModifiers = 0; >> >> - if ((modifiers & NSCommandKeyMask) != 0) javaModifiers |= >> java_awt_Event_META_MASK; >> - if ((modifiers & NSShiftKeyMask) != 0) javaModifiers |= >> java_awt_Event_SHIFT_MASK; >> - if ((modifiers & NSControlKeyMask) != 0) javaModifiers |= >> java_awt_Event_CTRL_MASK; >> - if ((modifiers & NSAlternateKeyMask) != 0) javaModifiers |= >> java_awt_Event_ALT_MASK; >> + NSEventType type = [currEvent type]; >> + if (type == NSKeyDown) { >> + NSString *menuKey = [sender keyEquivalent]; >> + NSString *eventKey = [currEvent characters]; >> + >> + if (![menuKey isEqualToString:eventKey]) { >> + // Only send the event if the NSEvent characters do not >> + // coincides with the NSMenuItem keyEquivalent. >> >> - JNFCallVoidMethod(env, fPeer, jm_handleAction, >> UTC(currEvent), javaModifiers); // AWT_THREADING Safe (event) >> + if ((modifiers & NSCommandKeyMask) != 0) >> javaModifiers |= java_awt_Event_META_MASK; >> + if ((modifiers & NSShiftKeyMask) != 0) >> javaModifiers |= java_awt_Event_SHIFT_MASK; >> + if ((modifiers & NSControlKeyMask) != 0) >> javaModifiers |= java_awt_Event_CTRL_MASK; >> + if ((modifiers & NSAlternateKeyMask) != 0) >> javaModifiers |= java_awt_Event_ALT_MASK; >> + >> + JNFCallVoidMethod(env, fPeer, jm_handleAction, >> UTC(currEvent), javaModifiers); // AWT_THREADING Safe (event) >> + } >> + } else { >> + JNFCallVoidMethod(env, fPeer, jm_handleAction, >> UTC(currEvent), javaModifiers); // AWT_THREADING Safe (event) >> + } >> + >> } >> JNF_COCOA_EXIT(env); >> } >> >> - (void) setJavaLabel:(NSString *)theLabel shortcut:(NSString >> *)theKeyEquivalent modifierMask:(jint)modifiers { >> AWT_ASSERT_NOT_APPKIT_THREAD; >> >> NSUInteger modifierMask = 0; >> exporting patch: >> >> >> >> Best, >> Marco > ` > > -- > Best regards, Sergey. > From marco.dinacci at gmail.com Wed Sep 5 11:56:05 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Wed, 5 Sep 2012 19:56:05 +0100 Subject: [PATCH] 7160951: ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: <3D7B6B3E-970A-4F6E-9A79-23C1E681D4B8@oracle.com> References: <50460C13.7070102@oracle.com> <3D7B6B3E-970A-4F6E-9A79-23C1E681D4B8@oracle.com> Message-ID: Hi Leonid, > Why do we need [menuKey isEqualToString:eventKey] check? If Cocoa has called our action callback and the type of the event which triggered that call is NSKeyDown, doesn't it mean we can be sure that a shortcut has been pressed? no because there's the case when a user select a menu item pressing space or enter. In this case the event is of type NSKeyDown but the keyEquivalent is empty. If this happens the event has to be propagated. Best, Marco From leonid.romanov at oracle.com Wed Sep 5 13:47:25 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 6 Sep 2012 00:47:25 +0400 Subject: [PATCH] 7160951: ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: References: <50460C13.7070102@oracle.com> <3D7B6B3E-970A-4F6E-9A79-23C1E681D4B8@oracle.com> Message-ID: Ah, I completely forgot about this possibility, thanks! ) I've done some testing and it seems like check box menu item suffers from the same problem, the only difference is that it is ItemListener that gets called twice. Overall, however, your fix is good. Since this bug is on me, I'll prepare a formal review and push it into 7u10/8, with you as a contributor. Leonid. On Sep 5, 2012, at 10:56 PM, Marco Dinacci wrote: > Hi Leonid, > >> Why do we need [menuKey isEqualToString:eventKey] check? If Cocoa has called our action callback and the type of the event which triggered that call is NSKeyDown, doesn't it mean we can be sure that a shortcut has been pressed? > > no because there's the case when a user select a menu item pressing > space or enter. > In this case the event is of type NSKeyDown but the keyEquivalent is > empty. If this happens the event has to be propagated. > > Best, > Marco From marco.dinacci at gmail.com Wed Sep 5 14:28:25 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Wed, 5 Sep 2012 22:28:25 +0100 Subject: [PATCH] 7160951: ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: References: <50460C13.7070102@oracle.com> <3D7B6B3E-970A-4F6E-9A79-23C1E681D4B8@oracle.com> Message-ID: Hi Leonid, > Ah, I completely forgot about this possibility, thanks! ) I've done some testing and it seems like check box menu item suffers from the same problem, the only difference is that it is ItemListener that gets called twice. Overall, however, your fix is good. > Since this bug is on me, I'll prepare a formal review and push it into 7u10/8, with you as a contributor. great news, thanks ! Best, Marco From Sergey.Bylokhov at oracle.com Thu Sep 6 04:29:37 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 06 Sep 2012 15:29:37 +0400 Subject: [7u10] Review request for 7172187 [macosx] JAWT native CALayer not positioned over Canvas Message-ID: <50488921.7020309@oracle.com> Hi Everyone, Please review the fix. This is direct backport from jdk 8. 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 jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/65d874d16d59 -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Sep 6 05:02:45 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 06 Sep 2012 16:02:45 +0400 Subject: [8] Review request for 7196547: [macosx] Implement dead key detection for KeyEvent Message-ID: <504890E5.2020407@oracle.com> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196547 webrev: http://cr.openjdk.java.net/~alexsch/7196547/webrev.00/ The characters method from the NSEvent class returns an empty string for dead keys. The fix uses the UCKeyTranslate() method to know a dead key state from the key code and key modifiers on the first step, and dead key state and space key to know the dead key char actual value on the second step. Thanks, Alexandr. From scott.kovatch at oracle.com Thu Sep 6 11:51:46 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 6 Sep 2012 11:51:46 -0700 Subject: [8] Review request for 7196547: [macosx] Implement dead key detection for KeyEvent In-Reply-To: <504890E5.2020407@oracle.com> References: <504890E5.2020407@oracle.com> Message-ID: Ah, UCKeyTranslate, how I've missed you. :-) This looks like pretty standard dead-key handling code, and looks fine to me. One very small point and not worth sending another review: at line 672 672 // out = [jkeyCode, jkeyLocation]; I would add the testDeadChar to the end of the comment. -- Scott K. On Sep 6, 2012, at 5:02 AM, Alexander Scherbatiy wrote: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196547 > webrev: http://cr.openjdk.java.net/~alexsch/7196547/webrev.00/ > > The characters method from the NSEvent class returns an empty string for dead keys. > The fix uses the UCKeyTranslate() method to know a dead key state from the key code and key modifiers on the first step, > and dead key state and space key to know the dead key char actual value on the second step. > > Thanks, > Alexandr. > From swingler at apple.com Thu Sep 6 17:14:14 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 06 Sep 2012 17:14:14 -0700 Subject: OSX Java application using awt always switches MacBook to discrete graphics. Bug or feature? In-Reply-To: <531D358C-AF0A-4737-8C72-709203A96FD9@claudio.ch> References: <531D358C-AF0A-4737-8C72-709203A96FD9@claudio.ch> Message-ID: <73B9EF7C-A2A2-40B0-9107-FF949EC2CEBF@apple.com> On Aug 30, 2012, at 12:35 PM, Claudio Nieder wrote: > Hi, > > I notice that all my Java applications which use AWT libraries in any form switches my MacBook Pro Retina to the (more battery consuming) discrete graphics mode, even when drawing very simple things. > > The following small program is enough to trigger the switch though it does not even open a window or draw anything. > > import java.awt.GraphicsEnvironment; > public class Sleep > { > public static final void main(final String[] args) throws InterruptedException > { > final GraphicsEnvironment b=GraphicsEnvironment.getLocalGraphicsEnvironment(); > Thread.sleep(Long.MAX_VALUE); > } > } > > Is this "bad behavior by design" or shall I file a bug report? > > I observe this with JDK 7u8-b04 on OS X 10.8.1 > $ java -version > java version "1.7.0_08-ea" > Java(TM) SE Runtime Environment (build 1.7.0_08-ea-b04) > Java HotSpot(TM) 64-Bit Server VM (build 23.4-b01, mixed mode) > $ uname -a > Darwin Claudios-MacBook-Pro.local 12.1.0 Darwin Kernel Version 12.1.0: Tue Aug 14 13:29:55 PDT 2012; root:xnu-2050.9.2~1/RELEASE_X86_64 x86_64 When in doubt, please file a bug report. (and no, this should not be the case - Java should fall back to integrated GPU, or software-only GL, dynamically, as the OS decides to change based on "current conditions", like if you are plugged into power or other external displays, etc). Regards, Mike Swingler Apple Inc. From leonid.romanov at oracle.com Fri Sep 7 11:41:58 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 7 Sep 2012 22:41:58 +0400 Subject: [8] Review request for 7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar Message-ID: <08E2360A-86F6-4845-9785-56386991107E@oracle.com> Hi, Please review a fix for 7160951: [macosx] ActionListener calle d twice for JMenuItem using ScreenMenuBar. Although a number of files have been changed, only CMenuItem.m changes constitutes the fix, the rest of the changes is a bit of code cleanup. The fix has been contributed by Marco Dinacci. Thanks! Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160951 Webrev: http://cr.openjdk.java.net/~leonidr/7160951/webrev.01/ Thanks, Leonid. From Sergey.Bylokhov at oracle.com Fri Sep 7 12:53:24 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 07 Sep 2012 23:53:24 +0400 Subject: [8] Review request for 7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: <08E2360A-86F6-4845-9785-56386991107E@oracle.com> References: <08E2360A-86F6-4845-9785-56386991107E@oracle.com> Message-ID: <504A50B4.4090505@oracle.com> Hi, Leonid. Why we cannot use javaExtMask everywhere in CMenuItem.java.setLabel(...) && CMenuItem.m ? 07.09.2012 22:41, Leonid Romanov wrote: > Hi, > Please review a fix for 7160951: [macosx] ActionListener called twice > for JMenuItem using ScreenMenuBar. Although a number of files have > been changed, only CMenuItem.m changes constitutes the fix, the rest > of the changes is a bit of code cleanup. > The fix has been contributed by Marco Dinacci. Thanks! > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160951 > Webrev: http://cr.openjdk.java.net/~leonidr/7160951/webrev.01/ > > > Thanks, > Leonid. -- Best regards, Sergey. From leonid.romanov at oracle.com Fri Sep 7 12:55:17 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 7 Sep 2012 23:55:17 +0400 Subject: [8] Review request for 7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: <504A50B4.4090505@oracle.com> References: <08E2360A-86F6-4845-9785-56386991107E@oracle.com> <504A50B4.4090505@oracle.com> Message-ID: <2BAF18FA-0221-4341-9F15-37DEF302F5E1@oracle.com> I dunno. I just did some cleanup of existing code, I didn't dig deeper. I'll investigate it. On Sep 7, 2012, at 11:53 PM, Sergey Bylokhov wrote: > Hi, Leonid. > Why we cannot use javaExtMask everywhere in CMenuItem.java.setLabel(...) && CMenuItem.m ? > > 07.09.2012 22:41, Leonid Romanov wrote: >> Hi, >> Please review a fix for 7160951: [macosx] ActionListener calle d twice for JMenuItem using ScreenMenuBar. Although a number of files have been changed, only CMenuItem.m changes constitutes the fix, the rest of the changes is a bit of code cleanup. >> The fix has been contributed by Marco Dinacci. Thanks! >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160951 >> Webrev: http://cr.openjdk.java.net/~leonidr/7160951/webrev.01/ >> >> Thanks, >> Leonid. > > > -- > Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Sep 7 13:13:16 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 08 Sep 2012 00:13:16 +0400 Subject: [8] Review request for 7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: <2BAF18FA-0221-4341-9F15-37DEF302F5E1@oracle.com> References: <08E2360A-86F6-4845-9785-56386991107E@oracle.com> <504A50B4.4090505@oracle.com> <2BAF18FA-0221-4341-9F15-37DEF302F5E1@oracle.com> Message-ID: <504A555C.6050706@oracle.com> In this case it would be good to check it in another CR. Fix itself looks good. 07.09.2012 23:55, Leonid Romanov wrote: > I dunno. I just did some cleanup of existing code, I didn't dig > deeper. I'll investigate it. > > On Sep 7, 2012, at 11:53 PM, Sergey Bylokhov > > wrote: > >> Hi, Leonid. >> Why we cannot use javaExtMask everywhere in >> CMenuItem.java.setLabel(...) && CMenuItem.m ? >> >> 07.09.2012 22:41, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7160951: [macosx] ActionListener called >>> twice for JMenuItem using ScreenMenuBar. Although a number of files >>> have been changed, only CMenuItem.m changes constitutes the fix, the >>> rest of the changes is a bit of code cleanup. >>> The fix has been contributed by Marco Dinacci. Thanks! >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160951 >>> Webrev: http://cr.openjdk.java.net/~leonidr/7160951/webrev.01/ >>> >>> >>> Thanks, >>> Leonid. >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From private at claudio.ch Fri Sep 7 16:04:33 2012 From: private at claudio.ch (Claudio Nieder) Date: Sat, 8 Sep 2012 01:04:33 +0200 Subject: OSX Java application using awt always switches MacBook to discrete graphics. Bug or feature? In-Reply-To: <73B9EF7C-A2A2-40B0-9107-FF949EC2CEBF@apple.com> References: <531D358C-AF0A-4737-8C72-709203A96FD9@claudio.ch> <73B9EF7C-A2A2-40B0-9107-FF949EC2CEBF@apple.com> Message-ID: <88AC73C9-4E63-476B-9A58-84A0B2D0B98C@claudio.ch> Hi, > When in doubt, please file a bug report. Done, should appear here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197045 In the mean time I have tested with Apple Java 1.6.0_35 and that one behaves as I would expect. claudio -- Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch From artem.ananiev at oracle.com Mon Sep 10 04:00:19 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 10 Sep 2012 15:00:19 +0400 Subject: [7u10] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <50472384.2000800@oracle.com> References: <50472384.2000800@oracle.com> Message-ID: <504DC843.30004@oracle.com> The fix looks fine. Please, add a comment to SMI.setLabel() and SMI.setShortcut() with explanation that we don't call to super methods from there. Thanks, Artem On 9/5/2012 2:03 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. This is backport from jdk8 to 7u10 > 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 > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f54660c18774 > From Sergey.Bylokhov at oracle.com Mon Sep 10 04:20:33 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 10 Sep 2012 15:20:33 +0400 Subject: [7u10] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <50472384.2000800@oracle.com> References: <50472384.2000800@oracle.com> Message-ID: <504DCD01.5020202@oracle.com> Hello Artem. Additional comments were added. New version of the fix. http://cr.openjdk.java.net/~serb/7186371/webrev.01/ Thanks. 05.09.2012 14:03, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. This is backport from jdk8 to 7u10 > 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 > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f54660c18774 > -- Best regards, Sergey. From scott.kovatch at oracle.com Mon Sep 10 09:28:46 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 10 Sep 2012 09:28:46 -0700 Subject: Cross-compiling from 10.8 to 10.7 Message-ID: Folks, I think we need to make some changes to the compiler options on the Mac. I'm finding that if you build the entire JDK as it is now on 10.8 with Xcode 4.4.1 it won't work when you drag the JDK or JRE back to a 10.7 machine. The official build machines are still on 10.7.4, and that's fine, but it would be good if we didn't have to make a local change to get a compatible build. And as new build machines become available, and have 10.8 pre-installed, this will become a problem. I'll try to address this sometime this week. I don't think it will be that tough, but if anyone has some spare cycles and a 10.8 and 10.7 system and would be willing to tackle it I'll happily review the patch. We know from appbundler and deploy that the only change needed is to add -mmacosx-version-min=10.7 to CFLAGS, but there are a couple of places (I think) where the base compiler options are set. We may also need -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk but I'm not convinced yet. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From leonid.romanov at oracle.com Mon Sep 10 09:52:11 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 10 Sep 2012 20:52:11 +0400 Subject: [7u10] Review request for 7124375: [macosx] Focus isn't transfered as expected between components Message-ID: <88732510-EF79-4A23-875D-826C98A9DF54@oracle.com> Hi, This is a back port of the fix that went into JDK 8. The main issue addressed by this fix is that information about current focused window and focus owner isn't shared among LWKeyboardFocusManagerPeer instances. Also, while the current KeyboardFocusManager code makes it look like each KeyboardFocusManager instance needs its own peer instance, the reality is different because both WKeyboardFocusManagerPeer and XKeyboardManagerPeer doesn't have non static fields. In other words, all the WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. Therefore, there is no need in in multiple peer instances, one singleton peer shared among all the KeyboardFocusManager instances is enough. This fix addresses that issue as well by explicitly turning KeyboardManagerPeer implementations into singletons for the sake of cleaner code. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.01/ Thanks, Leonid. From swingler at apple.com Mon Sep 10 09:57:11 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 10 Sep 2012 09:57:11 -0700 Subject: Cross-compiling from 10.8 to 10.7 In-Reply-To: References: Message-ID: <09446958-ACAC-47B5-9D9E-6C0AD6B992B5@apple.com> On Sep 10, 2012, at 9:28 AM, Scott Kovatch wrote: > Folks, > > I think we need to make some changes to the compiler options on the Mac. I'm finding that if you build the entire JDK as it is now on 10.8 with Xcode 4.4.1 it won't work when you drag the JDK or JRE back to a 10.7 machine. > > The official build machines are still on 10.7.4, and that's fine, but it would be good if we didn't have to make a local change to get a compatible build. And as new build machines become available, and have 10.8 pre-installed, this will become a problem. > > I'll try to address this sometime this week. I don't think it will be that tough, but if anyone has some spare cycles and a 10.8 and 10.7 system and would be willing to tackle it I'll happily review the patch. We know from appbundler and deploy that the only change needed is to add > > -mmacosx-version-min=10.7 > > to CFLAGS, but there are a couple of places (I think) where the base compiler options are set. We may also need > > -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk > > but I'm not convinced yet. -isysroot should not be necessary. Regards, Mike Swingler Apple Inc. From scott.kovatch at oracle.com Mon Sep 10 10:47:03 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 10 Sep 2012 10:47:03 -0700 Subject: Cross-compiling from 10.8 to 10.7 In-Reply-To: <09446958-ACAC-47B5-9D9E-6C0AD6B992B5@apple.com> References: <09446958-ACAC-47B5-9D9E-6C0AD6B992B5@apple.com> Message-ID: <58C54EA3-76FA-4CD2-8878-06D7A8784AAE@oracle.com> On Sep 10, 2012, at 9:57 AM, Mike Swingler wrote: > On Sep 10, 2012, at 9:28 AM, Scott Kovatch wrote: > >> Folks, >> >> I think we need to make some changes to the compiler options on the Mac. I'm finding that if you build the entire JDK as it is now on 10.8 with Xcode 4.4.1 it won't work when you drag the JDK or JRE back to a 10.7 machine. >> >> The official build machines are still on 10.7.4, and that's fine, but it would be good if we didn't have to make a local change to get a compatible build. And as new build machines become available, and have 10.8 pre-installed, this will become a problem. >> >> I'll try to address this sometime this week. I don't think it will be that tough, but if anyone has some spare cycles and a 10.8 and 10.7 system and would be willing to tackle it I'll happily review the patch. We know from appbundler and deploy that the only change needed is to add >> >> -mmacosx-version-min=10.7 >> >> to CFLAGS, but there are a couple of places (I think) where the base compiler options are set. We may also need >> >> -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk >> >> but I'm not convinced yet. > > -isysroot should not be necessary. Okay. I found that out the hard way. :-\ libdeploy is linked with /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork, which doesn't exist in 10.7. I haven't figured out why, as I don't explicitly link to it with -F. We use SystemConfiguration.framework; I'm not sure if that pulls it in or not. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From henri.gomez at gmail.com Mon Sep 10 11:09:23 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 10 Sep 2012 20:09:23 +0200 Subject: Cross-compiling from 10.8 to 10.7 In-Reply-To: <58C54EA3-76FA-4CD2-8878-06D7A8784AAE@oracle.com> References: <09446958-ACAC-47B5-9D9E-6C0AD6B992B5@apple.com> <58C54EA3-76FA-4CD2-8878-06D7A8784AAE@oracle.com> Message-ID: Interesting I'll track this thread carefully. I still don't have moved to ML to avoid such problems and be able to provide OpenJDK for Snow and Lion... Mike, Scott, advices and guideline more than welcome to get compile on 10.8 works in 10.7 and 10.6 2012/9/10 Scott Kovatch : > On Sep 10, 2012, at 9:57 AM, Mike Swingler wrote: > >> On Sep 10, 2012, at 9:28 AM, Scott Kovatch wrote: >> >>> Folks, >>> >>> I think we need to make some changes to the compiler options on the Mac. I'm finding that if you build the entire JDK as it is now on 10.8 with Xcode 4.4.1 it won't work when you drag the JDK or JRE back to a 10.7 machine. >>> >>> The official build machines are still on 10.7.4, and that's fine, but it would be good if we didn't have to make a local change to get a compatible build. And as new build machines become available, and have 10.8 pre-installed, this will become a problem. >>> >>> I'll try to address this sometime this week. I don't think it will be that tough, but if anyone has some spare cycles and a 10.8 and 10.7 system and would be willing to tackle it I'll happily review the patch. We know from appbundler and deploy that the only change needed is to add >>> >>> -mmacosx-version-min=10.7 >>> >>> to CFLAGS, but there are a couple of places (I think) where the base compiler options are set. We may also need >>> >>> -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk >>> >>> but I'm not convinced yet. >> >> -isysroot should not be necessary. > > Okay. I found that out the hard way. :-\ > > libdeploy is linked with /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork, which doesn't exist in 10.7. I haven't figured out why, as I don't explicitly link to it with -F. We use SystemConfiguration.framework; I'm not sure if that pulls it in or not. > > -- Scott K. > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > > > From anton.tarasov at oracle.com Tue Sep 11 02:14:46 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 11 Sep 2012 13:14:46 +0400 Subject: [7u10] Review request for 7124375: [macosx] Focus isn't transfered as expected between components In-Reply-To: <88732510-EF79-4A23-875D-826C98A9DF54@oracle.com> References: <88732510-EF79-4A23-875D-826C98A9DF54@oracle.com> Message-ID: <504F0106.5040501@oracle.com> Looks fine to me. Thanks, Anton. On 10.09.2012 20:52, Leonid Romanov wrote: > Hi, > This is a back port of the fix that went into JDK 8. > The main issue addressed by this fix is that information about current focused window and focus > owner isn't shared among LWKeyboardFocusManagerPeer instances. Also, while the current > KeyboardFocusManager code makes it look like each KeyboardFocusManager instance needs its own peer > instance, the reality is different because both WKeyboardFocusManagerPeer and XKeyboardManagerPeer > doesn't have non static fields. In other words, all the > WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. Therefore, there is no need in > in multiple peer instances, one singleton peer shared among all the KeyboardFocusManager instances > is enough. This fix addresses that issue as well by explicitly turning KeyboardManagerPeer > implementations into singletons for the sake of cleaner code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 > Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.01/ > > > Thanks, > Leonid. > From artem.ananiev at oracle.com Tue Sep 11 02:33:19 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 11 Sep 2012 13:33:19 +0400 Subject: [7u10] Review request for 7124375: [macosx] Focus isn't transfered as expected between components In-Reply-To: <88732510-EF79-4A23-875D-826C98A9DF54@oracle.com> References: <88732510-EF79-4A23-875D-826C98A9DF54@oracle.com> Message-ID: <504F055F.7040109@oracle.com> Hi, Leonid, the changes look fine. I would suggest a minor improvement, though. Right now setCurrentFocusedWindow() is only used on Mac OS X and X11. There is no need to add this method to KFM peer interface. Thanks, Artem On 9/10/2012 8:52 PM, Leonid Romanov wrote: > Hi, > This is a back port of the fix that went into JDK 8. > The main issue addressed by this fix is that information about current > focused window and focus owner isn't shared among > LWKeyboardFocusManagerPeer instances. Also, while the current > KeyboardFocusManager code makes it look like each KeyboardFocusManager > instance needs its own peer instance, the reality is different because > both WKeyboardFocusManagerPeer and XKeyboardManagerPeer doesn't have non > static fields. In other words, all the > WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. > Therefore, there is no need in in multiple peer instances, one singleton > peer shared among all the KeyboardFocusManager instances is enough. This > fix addresses that issue as well by explicitly turning > KeyboardManagerPeer implementations into singletons for the sake of > cleaner code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 > Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.01/ > > Thanks, > Leonid. > From artem.ananiev at oracle.com Tue Sep 11 02:34:52 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 11 Sep 2012 13:34:52 +0400 Subject: [7u10] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <504DCD01.5020202@oracle.com> References: <50472384.2000800@oracle.com> <504DCD01.5020202@oracle.com> Message-ID: <504F05BC.2000904@oracle.com> On 9/10/2012 3:20 PM, Sergey Bylokhov wrote: > Hello Artem. > Additional comments were added. > New version of the fix. > http://cr.openjdk.java.net/~serb/7186371/webrev.01/ Looks fine. Thanks, Artem > Thanks. > > 05.09.2012 14:03, Sergey Bylokhov wrote: >> Hi Everyone, >> Please review the fix. This is backport from jdk8 to 7u10 >> 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 >> jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f54660c18774 >> > > From anthony.petrov at oracle.com Tue Sep 11 05:52:39 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 11 Sep 2012 16:52:39 +0400 Subject: [8] Request for review: 7124523 [macosx] b216: Mising part of applet UI In-Reply-To: <5045EC63.3070700@oracle.com> References: <5045EC63.3070700@oracle.com> Message-ID: <504F3417.8070001@oracle.com> Looks fine. -- best regards, Anthony On 9/4/2012 3:56 PM, Sergey Bylokhov wrote: > Hello, > This is direct forward port from jdk 7u4 to jdk8. > The size of components is a bit bigger and one of the buttons simply > doesn't fit into the window. > Default size of the demo window should be increased. Two demos affected. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124523 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124523/webrev.00 > Technical review for jdk7u4: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003508.html > > From anthony.petrov at oracle.com Tue Sep 11 05:57:16 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 11 Sep 2012 16:57:16 +0400 Subject: [7u10] Review request for 7172187 [macosx] JAWT native CALayer not positioned over Canvas In-Reply-To: <50488921.7020309@oracle.com> References: <50488921.7020309@oracle.com> Message-ID: <504F352C.7020802@oracle.com> Looks good. -- best regards, Anthony On 9/6/2012 3:29 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. This is direct backport from jdk 8. > > 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 > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/65d874d16d59 > From anthony.petrov at oracle.com Tue Sep 11 08:52:06 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 11 Sep 2012 19:52:06 +0400 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac In-Reply-To: <504115F5.5090501@fastmail.fm> References: <502CB1ED.9070507@fastmail.fm> <502CEB07.40708@oracle.com> <503754BE.9000009@fastmail.fm> <50375C84.8030009@oracle.com> <50375F2A.1080304@fastmail.fm> <50376591.5040109@fastmail.fm> <5037665E.4090309@oracle.com> <503769E6.2020200@fastmail.fm> <50376AE0.9080102@oracle.com> <504115F5.5090501@fastmail.fm> Message-ID: <504F5E26.3070508@oracle.com> Hi Paul, On 8/31/2012 11:52 PM, Paul Taylor wrote: >>> Thats good news , but I am in fact using 1.7.0_08-ea, is there later >>> version of 7u8 or am I using the fix wrong Im doing >>> >>> System.setProperty("apple.awt.fileDialogForDirectories", >>> "true"); >>> FileDialog chooser = new FileDialog(MainWindow.frame); >>> chooser.setMode(FileDialog.LOAD); >>> chooser.setVisible(true); >>> String folderSelected = chooser.getDirectory(); >>> System.setProperty("apple.awt.fileDialogForDirectories", >>> "false"); >>> File folder = new File(folderSelected) ; >>> if(folder.exists() && folder.isDirectory()) >>> { >>> //DO something >>> } >>> >> >> The fix hasn't made it to the master repository yet. It is expected to >> appear in either 7u8b03 or 7u8b04. Maybe, in the worst case, in b05. >> Please check what build you're using with `java -version` and stay tuned. >> >> -- >> best regards, >> Anthony >> > Doesn't seem to have made it build 5 either, > > http://download.java.net/jdk7u8/changes/jdk7u8-b05.html > > problematic for me I cannot release my product until this problem is > resolved. According to the bug database, a fix for this issue (7161437) has been integrated in 7u10b06. And yes, 7u10 is what used to be called 7u8 in the past. Sorry for the confusion. Please try 7u10b06 once you have a chance and report if it works or not. JDK 8b55 should also contain this fix. -- best regards, Anthony From Sergey.Bylokhov at oracle.com Tue Sep 11 10:38:13 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 11 Sep 2012 21:38:13 +0400 Subject: [8] Review request for 7124213 and 7160627 Message-ID: <504F7705.7070003@oracle.com> Hi Everyone, Please review the fix for: 7124213 [macosx] pack() does ignore size of a component; doesn't on the other platforms. 7160627 [macosx] TextArea has wrong initial size Description of main changes: All our components were split into 3 groups: - Uses getPreferedSize()/getMinimumSise from swing delegetes. - Uses its own size as a preferedSize/minimumSize. - Uses its own implementation. Notes: LWContainerPeer is subclass of LWCanvasPeer now. We can share buffers methods in LWCanvasPeer and LWWindowPeer. All magic/system constants were removed. Now we relies on default look and feel as much as possible. Bugs: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160627 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124213 ** Webrev can be found at: http://cr.openjdk.java.net/~serb/7124213_7160627/webrev.00/ -- Best regards, Sergey. From leonid.romanov at oracle.com Wed Sep 12 05:30:40 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 12 Sep 2012 16:30:40 +0400 Subject: [7u10] Review request for 7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar Message-ID: <9F83D7A4-0336-46F4-929B-0109AB5E745F@oracle.com> Hi, Please review a fix for 7160951: [macosx] ActionListener calle d twice for JMenuItem using ScreenMenuBar. Although a number of files have been changed, only CMenuItem.m changes constitutes the fix, the rest of the changes is a bit of code cleanup. The fix has been contributed by Marco Dinacci. Thanks! Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160951 Webrev: http://cr.openjdk.java.net/~leonidr/7160951/webrev.02/ Thanks, Leonid. From Sergey.Bylokhov at oracle.com Wed Sep 12 05:32:11 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 12 Sep 2012 16:32:11 +0400 Subject: [7u10] Review request for 7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: <9F83D7A4-0336-46F4-929B-0109AB5E745F@oracle.com> References: <9F83D7A4-0336-46F4-929B-0109AB5E745F@oracle.com> Message-ID: <505080CB.7070504@oracle.com> Hi Leonid Fix looks good. 12.09.2012 16:30, Leonid Romanov wrote: > Hi, > Please review a fix for 7160951: [macosx] ActionListener called twice > for JMenuItem using ScreenMenuBar. Although a number of files have > been changed, only CMenuItem.m changes constitutes the fix, the rest > of the changes is a bit of code cleanup. > The fix has been contributed by Marco Dinacci. Thanks! > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160951 > Webrev: http://cr.openjdk.java.net/~leonidr/7160951/webrev.02/ > > > Thanks, > Leonid. -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Sep 12 05:36:50 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 12 Sep 2012 16:36:50 +0400 Subject: [7u10] Review request for 7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: <9F83D7A4-0336-46F4-929B-0109AB5E745F@oracle.com> References: <9F83D7A4-0336-46F4-929B-0109AB5E745F@oracle.com> Message-ID: <505081E2.2080805@oracle.com> Looks fine. -- best regards, Anthony On 9/12/2012 4:30 PM, Leonid Romanov wrote: > Hi, > Please review a fix for 7160951: [macosx] ActionListener calle d twice > for JMenuItem using ScreenMenuBar. Although a number of files have been > changed, only CMenuItem.m changes constitutes the fix, the rest of the > changes is a bit of code cleanup. > The fix has been contributed by Marco Dinacci. Thanks! > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160951 > Webrev: http://cr.openjdk.java.net/~leonidr/7160951/webrev.02/ > > Thanks, > Leonid. From anthony.petrov at oracle.com Wed Sep 12 05:50:18 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 12 Sep 2012 16:50:18 +0400 Subject: [8] Review request for 7124213 and 7160627 In-Reply-To: <504F7705.7070003@oracle.com> References: <504F7705.7070003@oracle.com> Message-ID: <5050850A.5040909@oracle.com> Hi Sergey, src/macosx/classes/sun/lwawt/LWComponentPeer.java > 880 * empty. In the XPeers or WPeers we use some magic constants, but here we > 881 * try to use something more useful, Why can't we use "some magic constants" here, and the constant 1 in particular? This choice may be relevant to components that display some text, but e.g. for a container component using text-based metrics doesn't look right. Also, I see that "w" was used previously, and you're changing this to "0". Perhaps "W" might work best? src/macosx/classes/sun/lwawt/LWContainerPeer.java > 43 abstract class LWContainerPeer > 44 extends LWCanvasPeer A Canvas peer implementation may be "heavier" since it can pull some graphics-related code which is unnecessary for simple containers. Do we really have to inherit from LWCanvasPeer here? Could we extract common code in a separate class and make container and canvas peers extend it instead? -- best regards, Anthony On 9/11/2012 9:38 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix for: > 7124213 [macosx] pack() does ignore size of a component; doesn't on the > other platforms. > 7160627 [macosx] TextArea has wrong initial size > > Description of main changes: > All our components were split into 3 groups: > - Uses getPreferedSize()/getMinimumSise from swing delegetes. > - Uses its own size as a preferedSize/minimumSize. > - Uses its own implementation. > > Notes: > LWContainerPeer is subclass of LWCanvasPeer now. We can share buffers > methods in LWCanvasPeer and LWWindowPeer. > All magic/system constants were removed. Now we relies on default look > and feel as much as possible. > > Bugs: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160627 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124213 > ** Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124213_7160627/webrev.00/ > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Wed Sep 12 06:42:19 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 12 Sep 2012 17:42:19 +0400 Subject: [8] Review request for 7124213 and 7160627 In-Reply-To: <5050850A.5040909@oracle.com> References: <504F7705.7070003@oracle.com> <5050850A.5040909@oracle.com> Message-ID: <5050913B.1080000@oracle.com> Hi, Anthony. See comments inline. 12.09.2012 16:50, Anthony Petrov wrote > Hi Sergey, > > src/macosx/classes/sun/lwawt/LWComponentPeer.java >> 880 * empty. In the XPeers or WPeers we use some magic >> constants, but here we >> 881 * try to use something more useful, > > Why can't we use "some magic constants" here, and the constant 1 in > particular? This choice may be relevant to components that display > some text, but e.g. for a container component using text-based metrics > doesn't look right. Containers uses getP/getM methods from the LWCanvasPeer. Default implementation in LWComponentPeer is applicable for usual components only. > Also, I see that "w" was used previously, and you're changing this to > "0". Perhaps "W" might work best? Just because it is used in the XToolkit and Wtoolkit.(WTextAreaPeer/XTextAreaPeer). > > src/macosx/classes/sun/lwawt/LWContainerPeer.java >> 43 abstract class LWContainerPeer> JComponent> >> 44 extends LWCanvasPeer > > A Canvas peer implementation may be "heavier" since it can pull some > graphics-related code which is unnecessary for simple containers. Most of the graphics code will be in the CGLGraphicsConfig. > > -- > best regards, > Anthony > > On 9/11/2012 9:38 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Please review the fix for: >> 7124213 [macosx] pack() does ignore size of a component; doesn't on >> the other platforms. >> 7160627 [macosx] TextArea has wrong initial size >> >> Description of main changes: >> All our components were split into 3 groups: >> - Uses getPreferedSize()/getMinimumSise from swing delegetes. >> - Uses its own size as a preferedSize/minimumSize. >> - Uses its own implementation. >> >> Notes: >> LWContainerPeer is subclass of LWCanvasPeer now. We can share buffers >> methods in LWCanvasPeer and LWWindowPeer. >> All magic/system constants were removed. Now we relies on default >> look and feel as much as possible. >> >> Bugs: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160627 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124213 >> ** Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7124213_7160627/webrev.00/ >> >> -- >> Best regards, Sergey. -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Sep 12 06:51:23 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 12 Sep 2012 17:51:23 +0400 Subject: [8] Review request for 7124213 and 7160627 In-Reply-To: <5050913B.1080000@oracle.com> References: <504F7705.7070003@oracle.com> <5050850A.5040909@oracle.com> <5050913B.1080000@oracle.com> Message-ID: <5050935B.9030709@oracle.com> On 9/12/2012 5:42 PM, Sergey Bylokhov wrote: > 12.09.2012 16:50, Anthony Petrov wrote >> src/macosx/classes/sun/lwawt/LWComponentPeer.java >>> 880 * empty. In the XPeers or WPeers we use some magic >>> constants, but here we >>> 881 * try to use something more useful, >> >> Why can't we use "some magic constants" here, and the constant 1 in >> particular? This choice may be relevant to components that display >> some text, but e.g. for a container component using text-based metrics >> doesn't look right. > Containers uses getP/getM methods from the LWCanvasPeer. Default > implementation in LWComponentPeer is applicable for usual components only. >> Also, I see that "w" was used previously, and you're changing this to >> "0". Perhaps "W" might work best? > Just because it is used in the XToolkit and > Wtoolkit.(WTextAreaPeer/XTextAreaPeer). Should we extract this constant to a java.awt.peer.* interface then for consistency across all toolkits? >> src/macosx/classes/sun/lwawt/LWContainerPeer.java >>> 43 abstract class LWContainerPeer>> JComponent> >>> 44 extends LWCanvasPeer >> >> A Canvas peer implementation may be "heavier" since it can pull some >> graphics-related code which is unnecessary for simple containers. > Most of the graphics code will be in the CGLGraphicsConfig. I see. But in the future we may want to modify the LWCanvasPeer, and this would also unintentionally affect the LWContainerPeer. I still suggest to extract all common code into a new abstract class. -- best regards, Anthony >> >> -- >> best regards, >> Anthony >> >> On 9/11/2012 9:38 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> Please review the fix for: >>> 7124213 [macosx] pack() does ignore size of a component; doesn't on >>> the other platforms. >>> 7160627 [macosx] TextArea has wrong initial size >>> >>> Description of main changes: >>> All our components were split into 3 groups: >>> - Uses getPreferedSize()/getMinimumSise from swing delegetes. >>> - Uses its own size as a preferedSize/minimumSize. >>> - Uses its own implementation. >>> >>> Notes: >>> LWContainerPeer is subclass of LWCanvasPeer now. We can share buffers >>> methods in LWCanvasPeer and LWWindowPeer. >>> All magic/system constants were removed. Now we relies on default >>> look and feel as much as possible. >>> >>> Bugs: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160627 >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124213 >>> ** Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7124213_7160627/webrev.00/ >>> >>> -- >>> Best regards, Sergey. > > From Sergey.Bylokhov at oracle.com Wed Sep 12 07:08:13 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 12 Sep 2012 18:08:13 +0400 Subject: [8] Review request for 7124213 and 7160627 In-Reply-To: <5050935B.9030709@oracle.com> References: <504F7705.7070003@oracle.com> <5050850A.5040909@oracle.com> <5050913B.1080000@oracle.com> <5050935B.9030709@oracle.com> Message-ID: <5050974D.4090805@oracle.com> 12.09.2012 17:51, Anthony Petrov wrote: > On 9/12/2012 5:42 PM, Sergey Bylokhov wrote: >> 12.09.2012 16:50, Anthony Petrov wrote >>> src/macosx/classes/sun/lwawt/LWComponentPeer.java >>>> 880 * empty. In the XPeers or WPeers we use some magic >>>> constants, but here we >>>> 881 * try to use something more useful, >>> >>> Why can't we use "some magic constants" here, and the constant 1 in >>> particular? This choice may be relevant to components that display >>> some text, but e.g. for a container component using text-based >>> metrics doesn't look right. >> Containers uses getP/getM methods from the LWCanvasPeer. Default >> implementation in LWComponentPeer is applicable for usual components >> only. >>> Also, I see that "w" was used previously, and you're changing this >>> to "0". Perhaps "W" might work best? >> Just because it is used in the XToolkit and >> Wtoolkit.(WTextAreaPeer/XTextAreaPeer). > > Should we extract this constant to a java.awt.peer.* interface then > for consistency across all toolkits? Well, possibility to change this constant for different toolkits should be. > >>> src/macosx/classes/sun/lwawt/LWContainerPeer.java >>>> 43 abstract class LWContainerPeer>>> JComponent> >>>> 44 extends LWCanvasPeer >>> >>> A Canvas peer implementation may be "heavier" since it can pull some >>> graphics-related code which is unnecessary for simple containers. >> Most of the graphics code will be in the CGLGraphicsConfig. > > I see. But in the future we may want to modify the LWCanvasPeer, and > this would also unintentionally affect the LWContainerPeer. I still > suggest to extract all common code into a new abstract class. Nobody knows that will be in the future. But actually, if I'll move all this code to the separate class our LWCanvasPeer becomes noop. Note that in the WToolkit/XToolkit, container is subclass of X/W.CanvasPeer. From this point of view this is unification across toolkits. > > -- > best regards, > Anthony > >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 9/11/2012 9:38 PM, Sergey Bylokhov wrote: >>>> Hi Everyone, >>>> Please review the fix for: >>>> 7124213 [macosx] pack() does ignore size of a component; doesn't on >>>> the other platforms. >>>> 7160627 [macosx] TextArea has wrong initial size >>>> >>>> Description of main changes: >>>> All our components were split into 3 groups: >>>> - Uses getPreferedSize()/getMinimumSise from swing delegetes. >>>> - Uses its own size as a preferedSize/minimumSize. >>>> - Uses its own implementation. >>>> >>>> Notes: >>>> LWContainerPeer is subclass of LWCanvasPeer now. We can share >>>> buffers methods in LWCanvasPeer and LWWindowPeer. >>>> All magic/system constants were removed. Now we relies on default >>>> look and feel as much as possible. >>>> >>>> Bugs: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160627 >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124213 >>>> ** Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7124213_7160627/webrev.00/ >>>> >>>> -- >>>> Best regards, Sergey. >> >> -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Wed Sep 12 07:58:06 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 12 Sep 2012 18:58:06 +0400 Subject: [8] Review request for 7197320: [macosx] Full Screen option missing when Window.documentModified Message-ID: <5050A2FE.3070306@oracle.com> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197320 webrev: http://cr.openjdk.java.net/~alexsch/7197320/webrev.00/ Fixing a typo in the mask checking for the full screen mode settings. Thanks, Alexandr. From anthony.petrov at oracle.com Wed Sep 12 08:54:11 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 12 Sep 2012 19:54:11 +0400 Subject: [8] Review request for 7197320: [macosx] Full Screen option missing when Window.documentModified In-Reply-To: <5050A2FE.3070306@oracle.com> References: <5050A2FE.3070306@oracle.com> Message-ID: <5050B023.5020304@oracle.com> Looks fine. -- best regards, Anthony On 9/12/2012 6:58 PM, Alexander Scherbatiy wrote: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197320 > webrev: http://cr.openjdk.java.net/~alexsch/7197320/webrev.00/ > > Fixing a typo in the mask checking for the full screen mode settings. > > Thanks, > Alexandr. > From paul_t100 at fastmail.fm Wed Sep 12 09:21:59 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 12 Sep 2012 17:21:59 +0100 Subject: JFileChooser not seeing network mounted files on 1.7.0_06 on Mac In-Reply-To: <504F5E26.3070508@oracle.com> References: <502CB1ED.9070507@fastmail.fm> <502CEB07.40708@oracle.com> <503754BE.9000009@fastmail.fm> <50375C84.8030009@oracle.com> <50375F2A.1080304@fastmail.fm> <50376591.5040109@fastmail.fm> <5037665E.4090309@oracle.com> <503769E6.2020200@fastmail.fm> <50376AE0.9080102@oracle.com> <504115F5.5090501@fastmail.fm> <504F5E26.3070508@oracle.com> Message-ID: <5050B6A7.3010607@fastmail.fm> On 11/09/2012 16:52, Anthony Petrov wrote: > Hi Paul, > > On 8/31/2012 11:52 PM, Paul Taylor wrote: >>>> Thats good news , but I am in fact using 1.7.0_08-ea, is there >>>> later version of 7u8 or am I using the fix wrong Im doing >>>> >>>> System.setProperty("apple.awt.fileDialogForDirectories", "true"); >>>> FileDialog chooser = new FileDialog(MainWindow.frame); >>>> chooser.setMode(FileDialog.LOAD); >>>> chooser.setVisible(true); >>>> String folderSelected = chooser.getDirectory(); >>>> System.setProperty("apple.awt.fileDialogForDirectories", "false"); >>>> File folder = new File(folderSelected) ; >>>> if(folder.exists() && folder.isDirectory()) >>>> { >>>> //DO something >>>> } >>>> >>> >>> The fix hasn't made it to the master repository yet. It is expected >>> to appear in either 7u8b03 or 7u8b04. Maybe, in the worst case, in >>> b05. Please check what build you're using with `java -version` and >>> stay tuned. >>> >>> -- >>> best regards, >>> Anthony >>> >> Doesn't seem to have made it build 5 either, >> >> http://download.java.net/jdk7u8/changes/jdk7u8-b05.html >> >> problematic for me I cannot release my product until this problem is >> resolved. > > According to the bug database, a fix for this issue (7161437) has been > integrated in 7u10b06. And yes, 7u10 is what used to be called 7u8 in > the past. Sorry for the confusion. > > Please try 7u10b06 once you have a chance and report if it works or > not. JDK 8b55 should also contain this fix. > > -- > best regards, > Anthony > HI Anthony Thankyou, I have now tried 7u10 and the fix is working :) Paul From alexander.zuev at oracle.com Thu Sep 13 07:51:48 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 13 Sep 2012 18:51:48 +0400 Subject: [8] Review request for 7196547: [macosx] Implement dead key detection for KeyEvent In-Reply-To: <504890E5.2020407@oracle.com> References: <504890E5.2020407@oracle.com> Message-ID: <5051F304.4050500@oracle.com> Fix looks ok to me. On 9/6/12 16:02, Alexander Scherbatiy wrote: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196547 > webrev: http://cr.openjdk.java.net/~alexsch/7196547/webrev.00/ > > The characters method from the NSEvent class returns an empty string > for dead keys. > The fix uses the UCKeyTranslate() method to know a dead key state > from the key code and key modifiers on the first step, > and dead key state and space key to know the dead key char actual > value on the second step. > > Thanks, > Alexandr. > From anthony.petrov at oracle.com Fri Sep 14 05:20:38 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 14 Sep 2012 16:20:38 +0400 Subject: [8] Review request for 7124213 and 7160627 In-Reply-To: <5050974D.4090805@oracle.com> References: <504F7705.7070003@oracle.com> <5050850A.5040909@oracle.com> <5050913B.1080000@oracle.com> <5050935B.9030709@oracle.com> <5050974D.4090805@oracle.com> Message-ID: <50532116.9070102@oracle.com> Thanks for the clarifications. I don't like how the code looks now, but the fix looks OK technically. -- best regards, Anthony On 9/12/2012 6:08 PM, Sergey Bylokhov wrote: > 12.09.2012 17:51, Anthony Petrov wrote: >> On 9/12/2012 5:42 PM, Sergey Bylokhov wrote: >>> 12.09.2012 16:50, Anthony Petrov wrote >>>> src/macosx/classes/sun/lwawt/LWComponentPeer.java >>>>> 880 * empty. In the XPeers or WPeers we use some magic >>>>> constants, but here we >>>>> 881 * try to use something more useful, >>>> >>>> Why can't we use "some magic constants" here, and the constant 1 in >>>> particular? This choice may be relevant to components that display >>>> some text, but e.g. for a container component using text-based >>>> metrics doesn't look right. >>> Containers uses getP/getM methods from the LWCanvasPeer. Default >>> implementation in LWComponentPeer is applicable for usual components >>> only. >>>> Also, I see that "w" was used previously, and you're changing this >>>> to "0". Perhaps "W" might work best? >>> Just because it is used in the XToolkit and >>> Wtoolkit.(WTextAreaPeer/XTextAreaPeer). >> >> Should we extract this constant to a java.awt.peer.* interface then >> for consistency across all toolkits? > Well, possibility to change this constant for different toolkits should be. >> >>>> src/macosx/classes/sun/lwawt/LWContainerPeer.java >>>>> 43 abstract class LWContainerPeer>>>> JComponent> >>>>> 44 extends LWCanvasPeer >>>> >>>> A Canvas peer implementation may be "heavier" since it can pull some >>>> graphics-related code which is unnecessary for simple containers. >>> Most of the graphics code will be in the CGLGraphicsConfig. >> >> I see. But in the future we may want to modify the LWCanvasPeer, and >> this would also unintentionally affect the LWContainerPeer. I still >> suggest to extract all common code into a new abstract class. > Nobody knows that will be in the future. But actually, if I'll move all > this code to the separate class our LWCanvasPeer becomes noop. Note that > in the WToolkit/XToolkit, container is subclass of X/W.CanvasPeer. From > this point of view this is unification across toolkits. >> >> -- >> best regards, >> Anthony >> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 9/11/2012 9:38 PM, Sergey Bylokhov wrote: >>>>> Hi Everyone, >>>>> Please review the fix for: >>>>> 7124213 [macosx] pack() does ignore size of a component; doesn't on >>>>> the other platforms. >>>>> 7160627 [macosx] TextArea has wrong initial size >>>>> >>>>> Description of main changes: >>>>> All our components were split into 3 groups: >>>>> - Uses getPreferedSize()/getMinimumSise from swing delegetes. >>>>> - Uses its own size as a preferedSize/minimumSize. >>>>> - Uses its own implementation. >>>>> >>>>> Notes: >>>>> LWContainerPeer is subclass of LWCanvasPeer now. We can share >>>>> buffers methods in LWCanvasPeer and LWWindowPeer. >>>>> All magic/system constants were removed. Now we relies on default >>>>> look and feel as much as possible. >>>>> >>>>> Bugs: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160627 >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124213 >>>>> ** Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/7124213_7160627/webrev.00/ >>>>> >>>>> -- >>>>> Best regards, Sergey. >>> >>> > > From steve at weblite.ca Sat Sep 15 13:04:05 2012 From: steve at weblite.ca (Steve Hannah) Date: Sat, 15 Sep 2012 13:04:05 -0700 Subject: AppBundler: wrong working directory In-Reply-To: References: <78DF6B3D-40AF-4FE0-81E7-8608D40DC459@oracle.com> <4E8C96C0-FDB9-4833-A1CC-DB5803ED0455@oracle.com> <07F11E88-B02B-485A-BFE8-E1A4ABF379F6@oracle.com> Message-ID: Sorry to revive an old thread, but I'm having some trouble on this exact issue, and the CWD approach doesn't seem to work on Lion. A solution that works (for setting the CWD) on Mountain Lion (with or without Sandboxing) is: 1. In the appbundler ANT task