AWT Dev hg: jdk8/awt/jdk: 7161766: [macosx] javax/swing/JPopupMenu/6694823/bug6694823.java failed on Mac OS X
Changeset: 0526ba7f723b Author:alexsch Date: 2012-06-04 14:11 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0526ba7f723b 7161766: [macosx] javax/swing/JPopupMenu/6694823/bug6694823.java failed on Mac OS X Reviewed-by: rupashka ! test/javax/swing/JPopupMenu/6694823/bug6694823.java
Re: AWT Dev [8] Review request for 6868690 TEST: java/awt/FontClass/CreateFont/BigFont.java test should be modified in jdk78 to run via jtreg
Hi, Konstantin, since you have replaced @run applet in .html with @run main in .java, does it also make sense to remove .html at all? Alternatively, you can keep the test as applet one, but mark it manual (@run applet/manual). BTW, copyright header dates should be updated to 2008, 2012, not 2008, 2011. Thanks, Artem On 5/31/2012 5:59 PM, Konstantin Shefov wrote: Hello, Please review a fix for the issue: 6868690 TEST: java/awt/FontClass/CreateFont/BigFont.java test should be modified in jdk78 to run via jtreg The webrev is http://cr.openjdk.java.net/~serb/6868690/webrev.00/ The test in the current state affects a whole session if it's executed under jtreg. It was fixed already by the implemented modifications in 1.7.0 that are used as a base for modifications applicable for 1.8.0 also. There is not risk are seen if the test be updated in jdk8 repo. The current fix is identical to already pushed fix for jdk 7. The test works in the automatic invocation (under jtreg) without bigfont.html file involvement. The only possible reason we may keep it (bigfont.html) for is - the test can be used in both the manual and automatic invocations. It include two methods runTest1() runTest2(). runTest2() is commented in the BigFont.java file as it's too risky to execute it in the automatic mode from the the applet environment. But it (runTest2()) is still valid for the manual invocation just for legacy/coverage reason to be executed under applet environment that is more challenging. As mentioned bigfont.html does not work in automatic invocation, but it can work if somebody decide to run the test manually (runTest2()) under applet environment. Thanks, Konstantin
Re: AWT Dev [7] Review request for 6891269: non-compliance with Section 508 using 1.6.0_18
Hi, Vladislav, some random comments: 1. From the bug description, it's not clear when the problem is reproducible. Does caret size become 1x1 pixels on windows theme changes? 2. AwtComponent class already has WmSettingsChanged() callback, so you can place ::SystemParametersInfo() there, not into AwtToolkit. 3. Does the problem only manifests in text areas? What about text fields? 4. Could you describe why UpdateCaret() is required in WmForwardChar() and in HandleEvent()? I would expect ::CreateCaret() in WmSetFocus(), ::DestroyCaret() in WmKillFocus(), and re-create caret in WmSettingChanged() should be enough. 5. If we introduce UpdateCaret() method, it should be placed either to AwtTextArea or to AwtTextComponent, there is no need to have this method in AwtComponent. Thanks, Artem On 6/1/2012 6:28 PM, Vladislav Karnaukhov wrote: Hello, please review a fix for the following issue: 6891269 non-compliance with Section 508 using 1.6.0_18 http://monaco.sfbay.sun.com/detail.jsf?cr=6891269 Please find webrev here: http://cr.openjdk.java.net/~alexp/6891269/webrev.00/ This is a forward-port from JDK6. The fix introduces support for Windows Accessibility/Ease Of Access to TextArea control. Regards, - Vlad
Re: AWT Dev [8] Review request for: 7172722: Latest jdk7u from OSX broke universal build
AWT/MacOSX-port-dev teams, Could I get a review for this one-line fix please? -- best regards, Anthony On 06/01/12 12:47, Henri Gomez wrote: Tested and it works for me. I just produced jdk7u b12 with it : http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u6-b12-20120601.dmg Cheers 2012/5/30 Anthony Petrovanthony.pet...@oracle.com: Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7172722 at: http://cr.openjdk.java.net/~anthony/8-33-MacUniversalBuild-7172722.0/ I've simplified the fix comparing to original Henri's proposal [1] to follow the same pattern as we use with other properties: we simply give the corresponding class fields the same names as to the properties themselves. Henri: please verify if the new patch works for you. [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-May/003191.html -- best regards, Anthony
Re: AWT Dev [8] Review request for: 7172722: Latest jdk7u from OSX broke universal build
Looks great. Mike Swingler Apple Inc. On Jun 4, 2012, at 7:48 AM, Anthony Petrov wrote: AWT/MacOSX-port-dev teams, Could I get a review for this one-line fix please? -- best regards, Anthony On 06/01/12 12:47, Henri Gomez wrote: Tested and it works for me. I just produced jdk7u b12 with it : http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u6-b12-20120601.dmg Cheers 2012/5/30 Anthony Petrovanthony.pet...@oracle.com: Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7172722 at: http://cr.openjdk.java.net/~anthony/8-33-MacUniversalBuild-7172722.0/ I've simplified the fix comparing to original Henri's proposal [1] to follow the same pattern as we use with other properties: we simply give the corresponding class fields the same names as to the properties themselves. Henri: please verify if the new patch works for you. [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-May/003191.html -- best regards, Anthony
Re: AWT Dev [8] Review request for: 7172722: Latest jdk7u from OSX broke universal build
Fix looks good. Thanks. 04.06.2012 18:48, Anthony Petrov wrote: AWT/MacOSX-port-dev teams, Could I get a review for this one-line fix please? -- best regards, Anthony On 06/01/12 12:47, Henri Gomez wrote: Tested and it works for me. I just produced jdk7u b12 with it : http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u6-b12-20120601.dmg Cheers 2012/5/30 Anthony Petrovanthony.pet...@oracle.com: Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7172722 at: http://cr.openjdk.java.net/~anthony/8-33-MacUniversalBuild-7172722.0/ I've simplified the fix comparing to original Henri's proposal [1] to follow the same pattern as we use with other properties: we simply give the corresponding class fields the same names as to the properties themselves. Henri: please verify if the new patch works for you. [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-May/003191.html -- best regards, Anthony -- Best regards, Sergey.
AWT Dev [8] Review request for 7124244: [macosx] Shaped windows support
Hi Everyone, Please review the fix. Shaped window was implemented as a translucent window with constrained graphics. Now translucent window doesn't use separate BufferedImage as a back buffer. Also alpha value for the swing back buffer was enabled(Shared code changed). Note that shaped windows are affected by this bugs: http://monaco.us.oracle.com/detail.jsf?cr=7124236 - Shadows disappear. - Transparent areas aren't transparent to mouse clicks. http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 - Opacity does not work for non opaque windows. Any suggestions are welcome. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.00 -- Best regards, Sergey.
AWT Dev hg: jdk8/awt/jdk: 7043963: AWT workaround missing for Mutter.
Changeset: 79df0a4a6573 Author:omajid Date: 2012-06-04 16:39 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/79df0a4a6573 7043963: AWT workaround missing for Mutter. Reviewed-by: art, anthony Contributed-by: Denis Lila dl...@redhat.com ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XWM.java + test/java/awt/WMSpecificTests/Mutter/MutterMaximizeTest.java ! test/java/awt/regtesthelpers/Util.java
Re: AWT Dev Add mutter as a window manager.
On 04/20/2012 11:01 AM, Artem Ananiev wrote: On 4/11/2012 11:21 PM, Anthony Petrov wrote: Hi Omair and Artem, On 4/11/2012 9:20 PM, Omair Majid wrote: PS. Perhaps it also makes sense to rewrite that comment in the XDecoratedPeer to replace the word bug with something saying that this is implemented according to the ICCCM specification with a reference to the paragraph 4.1.5 of it? Agreed. I would like to go so far as to make this the default, and add other window managers (which are deviating from ICCCM) as exceptions. I am afraid of introducing regressions, though. I wholeheartedly support this idea in theory. But it seems scary in practice. We would need to run all automatic and manual AWT regression tests on at least all major WMs (Metacity, Kwin, Compiz, and (sic!) CDE - as long as we support Solaris CDE desktops, not sure if this is relevant to JDK 8 though) to ensure no regressions arise. Note that we have to test this with quite old versions of the WMs, e.g. Metacity from Gnome 2.6 (or is it 2.4?) - this is what Solaris 10 has to offer, etc. And ideally we would also want to test on all those forgotten/rare creatures like SawFish, Motif, Enlightenment, etc. This looks like a lot of work for such a simple fix. However, your current fix looks pretty safe and is fully consistent with our current XAWT code. Artem, what's your opinion? Sorry for such a long delay from my side... Mario absolutely correctly wrote in his email: To be honest, I'm not that happy with the fix, but not because of Omair's patch, which is very fine given the current state of things, but because we keep adding this to each and every new WM we find, although fixing AWT in this regard will be probably more work than adding another exception to the list and an issue for perennial backward compatibility... and I feel exactly the same: the fix is fine, but the current AWT approach to workaround WM bugs isn't. Please, consider this as my approval :) Thanks. I have pushed the fix: http://hg.openjdk.java.net/jdk8/awt-gate/jdk/rev/79df0a4a6573 Cheers, Omair
Re: AWT Dev Add mutter as a window manager.
Hi Mario, On 04/11/2012 07:39 AM, Mario Torre wrote: I also agree with Omair. To be honest, I'm not that happy with the fix, but not because of Omair's patch, which is very fine given the current state of things, but because we keep adding this to each and every new WM we find, although fixing AWT in this regard will be probably more work than adding another exception to the list and an issue for perennial backward compatibility... Anyway, I just wanted to give Omair my +1 to this patch. Thanks for reviewing the patch. Unfortunately, since you are not listed as a reviewer for jdk8 [1], I couldnt list you as a reviewer in the changeset. Sorry about that. Thanks, Omair [1] http://openjdk.java.net/census#neugens
