From andrew.brygin at oracle.com Mon Mar 4 08:04:44 2013 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Mon, 04 Mar 2013 20:04:44 +0400 Subject: [8] request for review: 7152608: [macosx] Crash in liblwawt.dylib in AccelGlyphCache_RemoveCellInfo Message-ID: <5134C61C.1060609@oracle.com> Hello, could you please review forward port of the fix for 7152608 to jdk8? Bug: http://bugs.sun.com/view_bug.do?bug_id=7152608 Webrev: http://cr.openjdk.java.net/~bae/7152608/8/webrev.00/ The change is exactly same as for jdk7. Please take a look. Thanks, Andrew. From anton.tarasov at oracle.com Tue Mar 5 05:12:41 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 05 Mar 2013 17:12:41 +0400 Subject: [8] request for review: 7152608: [macosx] Crash in liblwawt.dylib in AccelGlyphCache_RemoveCellInfo In-Reply-To: <5134C61C.1060609@oracle.com> References: <5134C61C.1060609@oracle.com> Message-ID: <5135EF49.3050606@oracle.com> Hi Andrew, The changes look fine for me in general (though, I'm not an expert in this area). Thanks, Anton. On 04.03.2013 20:04, Andrew Brygin wrote: > Hello, > > could you please review forward port of the fix for 7152608 to jdk8? > > Bug: http://bugs.sun.com/view_bug.do?bug_id=7152608 > Webrev: http://cr.openjdk.java.net/~bae/7152608/8/webrev.00/ > > The change is exactly same as for jdk7. > > Please take a look. > > Thanks, > Andrew. From leonid.romanov at oracle.com Wed Mar 6 17:01:40 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 7 Mar 2013 05:01:40 +0400 Subject: [8] Review request for 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar Message-ID: <56EB7A89-FBF5-4AF4-9D28-2E514E6AFC42@oracle.com> Hi, Please review a fix for 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar. The problem manifests itself when VK_DELETE is used as a menu accelerator. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008366 Webrev: http://cr.openjdk.java.net/~leonidr/8008366/webrev.01/ Thanks, Leonid. From Sergey.Bylokhov at oracle.com Thu Mar 7 01:02:51 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 07 Mar 2013 13:02:51 +0400 Subject: [8] Review request for 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: <56EB7A89-FBF5-4AF4-9D28-2E514E6AFC42@oracle.com> References: <56EB7A89-FBF5-4AF4-9D28-2E514E6AFC42@oracle.com> Message-ID: <513857BB.5060408@oracle.com> Hi, Leonid. Fix looks good. 07.03.2013 5:01, Leonid Romanov wrote: > Hi, > Please review a fix for 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar. The problem manifests itself when VK_DELETE is used as a menu accelerator. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008366 > Webrev: http://cr.openjdk.java.net/~leonidr/8008366/webrev.01/ > > Thanks, > Leonid. > > > -- Best regards, Sergey. From anthony.petrov at oracle.com Thu Mar 7 04:09:46 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 07 Mar 2013 16:09:46 +0400 Subject: [8] Review request for 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar In-Reply-To: <56EB7A89-FBF5-4AF4-9D28-2E514E6AFC42@oracle.com> References: <56EB7A89-FBF5-4AF4-9D28-2E514E6AFC42@oracle.com> Message-ID: <5138838A.8080909@oracle.com> Looks fine. -- best regards, Anthony On 03/07/13 05:01, Leonid Romanov wrote: > Hi, > Please review a fix for 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar. The problem manifests itself when VK_DELETE is used as a menu accelerator. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008366 > Webrev: http://cr.openjdk.java.net/~leonidr/8008366/webrev.01/ > > Thanks, > Leonid. > > > From weijun.wang at oracle.com Sun Mar 10 21:58:40 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 11 Mar 2013 12:58:40 +0800 Subject: code review request: 8009752: Let SCDynamicStoreConfig return raw info Message-ID: <513D6480.3030000@oracle.com> Please review the code changes at http://cr.openjdk.java.net/~weijun/8009752/webrev.00/ On OS X we use SCDynamicStoreConfig to read krb5.conf-like info. Currently the native method in SCDynamicStoreConfig.m returns a data structure that mimics the internal data structure inside sun/security/krb5/Config.java. If we decide to refactor Config to support more features (for example, 7153718) and the data structure needs to be adjusted, SCDynamicStoreConfig.m must be updated also. This code change includes: 1. Modify SCDynamicStoreConfig.m so that getConfig0(key) can read anything inside SCDynamicStore (just like a "list key" call in scutil), and the output is the raw structure inside the store. 2. Convert these info to Config-style inside SCDynamicStoreConfig.java. If we want to modify Config internal data in the future, we just need to update SCDynamicStoreConfig.java. No more native codes will be touched. A regression test is provided to partially test the correctness of conversion in the java part. A real test on Mac OS X server will be needed to fully test the code changes. I've personally checked in on my own machine. Thanks Max From paul_t100 at fastmail.fm Mon Mar 11 14:06:58 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Mon, 11 Mar 2013 21:06:58 +0000 Subject: Using Application.getApplication().setDockIconImage() Message-ID: <513E4772.3060704@fastmail.fm> When I minimize the main window of my application can you set the image of the minimized window on the dock with Application.getApplication().setDockIconImage() or is that for the application icon on the dock. Apologies if I'm using the wrong terminology, I'm not an OSX native. If this is true,is there way to automatically set the image to a representation of the window with a minimized icon image at the lower right handside, as this seems to be what other applications do. Paul From swingler at apple.com Mon Mar 11 14:26:56 2013 From: swingler at apple.com (Mike Swingler) Date: Mon, 11 Mar 2013 14:26:56 -0700 Subject: Using Application.getApplication().setDockIconImage() In-Reply-To: <513E4772.3060704@fastmail.fm> References: <513E4772.3060704@fastmail.fm> Message-ID: <812AEC60-A534-4B65-821F-6028BACE0298@apple.com> On Mar 11, 2013, at 2:06 PM, Paul Taylor wrote: > When I minimize the main window of my application can you set the image of the minimized window on the dock with > > Application.getApplication().setDockIconImage() > > or is that for the application icon on the dock. > > Apologies if I'm using the wrong terminology, I'm not an OSX native. > > If this is true,is there way to automatically set the image to a representation of the window with a minimized icon image at the lower right handside, as this seems to be what other applications do. Application.setDockIconImage() is only for the application icon. If you want the default behavior (show a miniature version of the window) for a frame *do not* call Frame.setIconImage(). Regards, Mike Swingler Apple Inc. From ajgregory at gmail.com Mon Mar 11 15:02:05 2013 From: ajgregory at gmail.com (AJ Gregory) Date: Mon, 11 Mar 2013 15:02:05 -0700 Subject: Java 7 and Application.setOpenURIHandler In-Reply-To: References: Message-ID: I submitted a bug for this but it's been "not available" for a few weeks: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000081 Can anybody comment on this issue with the Application.setOpenURIHandler and custom protocols? Custom protocols really are useful especially now that applets are dying a slow death with everybody disabling java in their browser... Thanks, -Aj On Mon, Feb 18, 2013 at 7:28 PM, AJ Gregory wrote: > I have an app bundled with Java 7 (1.7.0_13) which registers a custom > URL scheme using CFBundleURLSchemes in it's Info.plist and uses the > Application.setOpenURIHandler to register a listener. > > When I click on a link that has the custom URL scheme in the browser > it launches the app OK but doesn't call the handler and the following > dump is in the console. > > I tried to submitted a bug as well but never got a bug number so not > sure if it was created. > > Anybody else have experience with this? > > Thanks, > -Aj > > > > 2/6/13 8:46:21.473 AM JavaAppLauncher[842]: ( > 0 CoreFoundation 0x00007fff898200a6 > __exceptionPreprocess + 198 > 1 libobjc.A.dylib 0x00007fff840043f0 > objc_exception_throw + 43 > 2 CoreFoundation 0x00007fff8981fe7c > +[NSException raise:format:] + 204 > 3 Foundation 0x00007fff8c29f763 > -[NSAppleEventDescriptor paramDescriptorForKeyword:] + 71 > 4 liblwawt.dylib 0x0000000168fb2b77 > -[ApplicationDelegate _handleOpenURLEvent: > withReplyEvent:] + 137 > 5 libosxapp.dylib 0x00000001690588b1 > __-[QueuingApplicationDelegate > _handleOpenURLEvent:withReplyEvent:]_block_invoke_1 + 135 > 6 libosxapp.dylib 0x00000001690597bf > -[QueuingApplicationDelegate processQueuedEventsWithTargetDelegate:] + > 134 > 7 libosxapp.dylib 0x0000000169057857 > OSXAPP_SetApplicationDelegate + 153 > 8 liblwawt.dylib 0x0000000168fb1899 > __+[AWTStarter start:swtMode:swtModeForWebStart:]_block_invoke_1 + 111 > 9 Foundation 0x00007fff8c2cf677 > __NSThreadPerformPerform + 225 > 10 CoreFoundation 0x00007fff8979f101 > __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 11 CoreFoundation 0x00007fff8979ea25 > __CFRunLoopDoSources0 + 245 > 12 CoreFoundation 0x00007fff897c1dc5 > __CFRunLoopRun + 789 > 13 CoreFoundation 0x00007fff897c16b2 > CFRunLoopRunSpecific + 290 > 14 HIToolbox 0x00007fff872880a4 > RunCurrentEventLoopInMode + 209 > 15 HIToolbox 0x00007fff87287d84 > ReceiveNextEventCommon + 166 > 16 HIToolbox 0x00007fff87287cd3 > BlockUntilNextEventMatchingListInMode + 62 > 17 AppKit 0x00007fff8e331613 > _DPSNextEvent + 685 > 18 AppKit 0x00007fff8e330ed2 > -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 > 19 libosxapp.dylib 0x0000000169057b56 > -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + > 124 > 20 AppKit 0x00007fff8e328283 > -[NSApplication run] + 517 > 21 libosxapp.dylib 0x00000001690579b9 > +[NSApplicationAWT runAWTLoopWithApp:] + 156 > 22 liblwawt.dylib 0x0000000168fb181a > -[AWTStarter starter:] + 1591 > 23 Foundation 0x00007fff8c2cf677 > __NSThreadPerformPerform + 225 > 24 CoreFoundation 0x00007fff8979f101 > __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 25 CoreFoundation 0x00007fff8979ea25 > __CFRunLoopDoSources0 + 245 > 26 CoreFoundation 0x00007fff897c1dc5 > __CFRunLoopRun + 789 > 27 CoreFoundation 0x00007fff897c16b2 > CFRunLoopRunSpecific + 290 > 28 libjli.dylib 0x00000001001cb88d > CreateExecutionEnvironment + 871 > 29 libjli.dylib 0x00000001001c603c JLI_Launch + 1952 > 30 JavaAppLauncher 0x00000001000629cb launch + 5035 > 31 JavaAppLauncher 0x00000001000614f6 main + 102 > 32 JavaAppLauncher 0x0000000100061484 start + 52 > 33 ??? 0x0000000000000002 0x0 + 2 > ) From pflahrty at rampageinc.com Mon Mar 11 16:35:58 2013 From: pflahrty at rampageinc.com (Patrick Flaherty) Date: Mon, 11 Mar 2013 19:35:58 -0400 Subject: Request for update on a bug Message-ID: <99FF4F81-1A90-4C84-B952-0FD1828ACD47@rampageinc.com> Hi, Can anyone tell me how to find out about a outstanding bug in Java 7 for the Mac platform? The bug id is http://bugs.sun.com/bugdatabase/view_bug.do? bug_id=7190349. The bug is a Java 2D bug involving rotated text. It was submitted back in last August. Thanks for any help. -Pat From paul_t100 at fastmail.fm Tue Mar 12 03:15:31 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 12 Mar 2013 10:15:31 +0000 Subject: Using Application.getApplication().setDockIconImage() In-Reply-To: <812AEC60-A534-4B65-821F-6028BACE0298@apple.com> References: <513E4772.3060704@fastmail.fm> <812AEC60-A534-4B65-821F-6028BACE0298@apple.com> Message-ID: <513F0043.7030200@fastmail.fm> On 11/03/2013 21:26, Mike Swingler wrote: > On Mar 11, 2013, at 2:06 PM, Paul Taylor wrote: > >> When I minimize the main window of my application can you set the image of the minimized window on the dock with >> >> Application.getApplication().setDockIconImage() >> >> or is that for the application icon on the dock. >> >> Apologies if I'm using the wrong terminology, I'm not an OSX native. >> >> If this is true,is there way to automatically set the image to a representation of the window with a minimized icon image at the lower right handside, as this seems to be what other applications do. > Application.setDockIconImage() is only for the application icon. > > If you want the default behavior (show a miniature version of the window) for a frame *do not* call Frame.setIconImage(). Ah, thanks Mike that was easy Paul From Sergey.Bylokhov at oracle.com Tue Mar 12 10:56:54 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 12 Mar 2013 21:56:54 +0400 Subject: [8] Request for review: 8000435: [macosx] Button painting error under Java 7 on Mac Message-ID: <513F6C66.40306@oracle.com> Hello, Please review the fix for jdk 8. Fix will be ported to jdk7 as well. This is a tweak of the code which mimic some macosx constant. The problem was in the assumption that we can paint native buttons with the height of >=18 pixel(28 - 5 - 5 ), but currently it should be >=24(28 - 2 - 2). In AquaButtonExtendedTypes constants in alterInsets() were changed to be less strict. http://cr.openjdk.java.net/~serb/8000435/before_segmentedRoundRect_first_small.png http://cr.openjdk.java.net/~serb/8000435/after_segmentedRoundRect_first_small.png Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000435 Webrev can be found at: http://cr.openjdk.java.net/~serb/8000435/webrev.00/ -- Best regards, Sergey. From Abhinay.Reddyreddy at mathworks.com Tue Mar 12 11:41:17 2013 From: Abhinay.Reddyreddy at mathworks.com (Abhinay Reddyreddy) Date: Tue, 12 Mar 2013 18:41:17 +0000 Subject: [macosx] Java 7 print dialog creates a new window on app-switch. Message-ID: <353D880645CCDC429732D7A445F7F5BF461E6F50@exmb-01-ah.ad.mathworks.com> I have noticed a bug in Java 7 print dialog on Mac. I have reported it to bugs.sun.com but did not receive any response. Could someone confirm if this bug has been noticed and fixed or if there is any workaround for it. Thanks, Abhinay. Issue: An extra window is created at the top-left corner of the screen, if a user switches the app while it is showing a native print dialog. Steps to reproduce: Run the attached code click print button when the native print dialog shows up, switch to a different app using Cmd+Tab or mouse switch back to the java app with print dialog notice a new window is created at the top right corner of the screen. java -version java version "1.7.0_13" Java(TM) SE Runtime Environment (build 1.7.0_13-b20) Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) import javax.swing.SwingUtilities; import java.awt.FlowLayout; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.awt.print.PrinterJob; import javax.print.attribute.HashPrintRequestAttributeSet; import javax.print.attribute.PrintRequestAttributeSet; import javax.print.attribute.standard.DialogTypeSelection; import javax.swing.JButton; import javax.swing.JFrame; import java.awt.print.PrinterException; public class PrintDialogTestCase extends JFrame { public PrintDialogTestCase() { this.setTitle("Example"); this.setSize(200, 100); this.setLocationRelativeTo(null); this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); this.setLayout(new FlowLayout()); JButton printDialogButton = new JButton("Print Dialog"); printDialogButton.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent event) { final PrintRequestAttributeSet attributes = new HashPrintRequestAttributeSet(); attributes.add(DialogTypeSelection.NATIVE); PrinterJob printJob = PrinterJob.getPrinterJob(); if(printJob.printDialog(attributes)) { try { printJob.print(); } catch (PrinterException pe) { } } } }); this.add(printDialogButton); JButton exitButton = new JButton("Exit"); exitButton.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent event) { System.exit(0); } }); this.add(exitButton); } public static void main(String[] args) { SwingUtilities.invokeLater(new Runnable() { @Override public void run() { PrintDialogTestCase window = new PrintDialogTestCase(); window.setVisible(true); } }); } } From petr.pchelko at oracle.com Tue Mar 12 11:57:15 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 12 Mar 2013 22:57:15 +0400 Subject: [macosx] Java 7 print dialog creates a new window on app-switch. In-Reply-To: <353D880645CCDC429732D7A445F7F5BF461E6F50@exmb-01-ah.ad.mathworks.com> References: <353D880645CCDC429732D7A445F7F5BF461E6F50@exmb-01-ah.ad.mathworks.com> Message-ID: <0DE78353-DD14-47D7-8F04-20FF90789548@oracle.com> Hello, Abhinay. The bug probably duplicated the following issue: http://bugs.sun.com/view_bug.do?bug_id=8005997 The issue is fixed in jdk 8, however it was not yet back ported to jdk7 updates. With best regards. Petr. 12.03.2013, ? 22:41, Abhinay Reddyreddy ???????(?): > > I have noticed a bug in Java 7 print dialog on Mac. I have reported it to bugs.sun.com but did not receive any response. > Could someone confirm if this bug has been noticed and fixed or if there is any workaround for it. > > Thanks, > Abhinay. > > Issue: An extra window is created at the top-left corner of the screen, if a user switches the app while it is showing a native print dialog. > > Steps to reproduce: > Run the attached code > click print button > when the native print dialog shows up, switch to a different app using Cmd+Tab or mouse > switch back to the java app with print dialog > notice a new window is created at the top right corner of the screen. > > java -version > java version "1.7.0_13" > Java(TM) SE Runtime Environment (build 1.7.0_13-b20) > Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) > > > import javax.swing.SwingUtilities; > import java.awt.FlowLayout; > import java.awt.event.ActionEvent; > import java.awt.event.ActionListener; > import java.awt.print.PrinterJob; > import javax.print.attribute.HashPrintRequestAttributeSet; > import javax.print.attribute.PrintRequestAttributeSet; > import javax.print.attribute.standard.DialogTypeSelection; > import javax.swing.JButton; > import javax.swing.JFrame; > import java.awt.print.PrinterException; > > public class PrintDialogTestCase extends JFrame { > public PrintDialogTestCase() { > this.setTitle("Example"); > this.setSize(200, 100); > this.setLocationRelativeTo(null); > this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > > this.setLayout(new FlowLayout()); > > JButton printDialogButton = new JButton("Print Dialog"); > printDialogButton.addActionListener(new ActionListener() { > public void actionPerformed(ActionEvent event) { > final PrintRequestAttributeSet attributes = new HashPrintRequestAttributeSet(); > attributes.add(DialogTypeSelection.NATIVE); > PrinterJob printJob = PrinterJob.getPrinterJob(); > if(printJob.printDialog(attributes)) > { > try { > printJob.print(); > } catch (PrinterException pe) { > } > } > > } > }); > this.add(printDialogButton); > > JButton exitButton = new JButton("Exit"); > exitButton.addActionListener(new ActionListener() { > public void actionPerformed(ActionEvent event) { > System.exit(0); > } > }); > this.add(exitButton); > } > public static void main(String[] args) { > SwingUtilities.invokeLater(new Runnable() { > @Override > public void run() { > PrintDialogTestCase window = new PrintDialogTestCase(); > window.setVisible(true); > } > }); > > } > } > From Sergey.Bylokhov at oracle.com Tue Mar 12 12:05:38 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 12 Mar 2013 23:05:38 +0400 Subject: [macosx] Java 7 print dialog creates a new window on app-switch. In-Reply-To: <353D880645CCDC429732D7A445F7F5BF461E6F50@exmb-01-ah.ad.mathworks.com> References: <353D880645CCDC429732D7A445F7F5BF461E6F50@exmb-01-ah.ad.mathworks.com> Message-ID: <513F7C82.5080705@oracle.com> Hi, Abhinay. Thanks for your report! Your bug is a duplicate of 8005997, which was fixed in jdk 8. http://bugs.sun.com/view_bug.do?bug_id=8005997 Hi, Petr I assume in jdk 7 it could be fixed too? 12.03.2013 22:41, Abhinay Reddyreddy wrote: > I have noticed a bug in Java 7 print dialog on Mac. I have reported it to bugs.sun.com but did not receive any response. > Could someone confirm if this bug has been noticed and fixed or if there is any workaround for it. > > Thanks, > Abhinay. > > Issue: An extra window is created at the top-left corner of the screen, if a user switches the app while it is showing a native print dialog. > > Steps to reproduce: > Run the attached code > click print button > when the native print dialog shows up, switch to a different app using Cmd+Tab or mouse > switch back to the java app with print dialog > notice a new window is created at the top right corner of the screen. > > java -version > java version "1.7.0_13" > Java(TM) SE Runtime Environment (build 1.7.0_13-b20) > Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) > > > import javax.swing.SwingUtilities; > import java.awt.FlowLayout; > import java.awt.event.ActionEvent; > import java.awt.event.ActionListener; > import java.awt.print.PrinterJob; > import javax.print.attribute.HashPrintRequestAttributeSet; > import javax.print.attribute.PrintRequestAttributeSet; > import javax.print.attribute.standard.DialogTypeSelection; > import javax.swing.JButton; > import javax.swing.JFrame; > import java.awt.print.PrinterException; > > public class PrintDialogTestCase extends JFrame { > public PrintDialogTestCase() { > this.setTitle("Example"); > this.setSize(200, 100); > this.setLocationRelativeTo(null); > this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > > this.setLayout(new FlowLayout()); > > JButton printDialogButton = new JButton("Print Dialog"); > printDialogButton.addActionListener(new ActionListener() { > public void actionPerformed(ActionEvent event) { > final PrintRequestAttributeSet attributes = new HashPrintRequestAttributeSet(); > attributes.add(DialogTypeSelection.NATIVE); > PrinterJob printJob = PrinterJob.getPrinterJob(); > if(printJob.printDialog(attributes)) > { > try { > printJob.print(); > } catch (PrinterException pe) { > } > } > > } > }); > this.add(printDialogButton); > > JButton exitButton = new JButton("Exit"); > exitButton.addActionListener(new ActionListener() { > public void actionPerformed(ActionEvent event) { > System.exit(0); > } > }); > this.add(exitButton); > } > public static void main(String[] args) { > SwingUtilities.invokeLater(new Runnable() { > @Override > public void run() { > PrintDialogTestCase window = new PrintDialogTestCase(); > window.setVisible(true); > } > }); > > } > } > -- Best regards, Sergey. From petr.pchelko at oracle.com Tue Mar 12 12:13:08 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 12 Mar 2013 23:13:08 +0400 Subject: [macosx] Java 7 print dialog creates a new window on app-switch. In-Reply-To: <513F7C82.5080705@oracle.com> References: <353D880645CCDC429732D7A445F7F5BF461E6F50@exmb-01-ah.ad.mathworks.com> <513F7C82.5080705@oracle.com> Message-ID: <0801D9D0-F8D6-43F5-A54E-C1EA7D04F300@oracle.com> > Hi, Petr > I assume in jdk 7 it could be fixed too? The fix is very simple, I suppose it would be applicable to the jdk7. With best regards. Petr. 12.03.2013, ? 23:05, Sergey Bylokhov ???????(?): > Hi, Abhinay. > Thanks for your report! > Your bug is a duplicate of 8005997, which was fixed in jdk 8. > http://bugs.sun.com/view_bug.do?bug_id=8005997 > > Hi, Petr > I assume in jdk 7 it could be fixed too? > > 12.03.2013 22:41, Abhinay Reddyreddy wrote: >> I have noticed a bug in Java 7 print dialog on Mac. I have reported it to bugs.sun.com but did not receive any response. >> Could someone confirm if this bug has been noticed and fixed or if there is any workaround for it. >> >> Thanks, >> Abhinay. >> >> Issue: An extra window is created at the top-left corner of the screen, if a user switches the app while it is showing a native print dialog. >> >> Steps to reproduce: >> Run the attached code >> click print button >> when the native print dialog shows up, switch to a different app using Cmd+Tab or mouse >> switch back to the java app with print dialog >> notice a new window is created at the top right corner of the screen. >> >> java -version >> java version "1.7.0_13" >> Java(TM) SE Runtime Environment (build 1.7.0_13-b20) >> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) >> >> >> import javax.swing.SwingUtilities; >> import java.awt.FlowLayout; >> import java.awt.event.ActionEvent; >> import java.awt.event.ActionListener; >> import java.awt.print.PrinterJob; >> import javax.print.attribute.HashPrintRequestAttributeSet; >> import javax.print.attribute.PrintRequestAttributeSet; >> import javax.print.attribute.standard.DialogTypeSelection; >> import javax.swing.JButton; >> import javax.swing.JFrame; >> import java.awt.print.PrinterException; >> >> public class PrintDialogTestCase extends JFrame { >> public PrintDialogTestCase() { >> this.setTitle("Example"); >> this.setSize(200, 100); >> this.setLocationRelativeTo(null); >> this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> >> this.setLayout(new FlowLayout()); >> >> JButton printDialogButton = new JButton("Print Dialog"); >> printDialogButton.addActionListener(new ActionListener() { >> public void actionPerformed(ActionEvent event) { >> final PrintRequestAttributeSet attributes = new HashPrintRequestAttributeSet(); >> attributes.add(DialogTypeSelection.NATIVE); >> PrinterJob printJob = PrinterJob.getPrinterJob(); >> if(printJob.printDialog(attributes)) >> { >> try { >> printJob.print(); >> } catch (PrinterException pe) { >> } >> } >> >> } >> }); >> this.add(printDialogButton); >> >> JButton exitButton = new JButton("Exit"); >> exitButton.addActionListener(new ActionListener() { >> public void actionPerformed(ActionEvent event) { >> System.exit(0); >> } >> }); >> this.add(exitButton); >> } >> public static void main(String[] args) { >> SwingUtilities.invokeLater(new Runnable() { >> @Override >> public void run() { >> PrintDialogTestCase window = new PrintDialogTestCase(); >> window.setVisible(true); >> } >> }); >> >> } >> } >> > > > -- > Best regards, Sergey. > From Abhinay.Reddyreddy at mathworks.com Tue Mar 12 12:37:58 2013 From: Abhinay.Reddyreddy at mathworks.com (Abhinay Reddyreddy) Date: Tue, 12 Mar 2013 19:37:58 +0000 Subject: [macosx] Java 7 print dialog creates a new window on app-switch. In-Reply-To: <0801D9D0-F8D6-43F5-A54E-C1EA7D04F300@oracle.com> References: <353D880645CCDC429732D7A445F7F5BF461E6F50@exmb-01-ah.ad.mathworks.com> <513F7C82.5080705@oracle.com> <0801D9D0-F8D6-43F5-A54E-C1EA7D04F300@oracle.com> Message-ID: <353D880645CCDC429732D7A445F7F5BF461E7200@exmb-01-ah.ad.mathworks.com> Thanks for the fast response. It would be awesome if this issue could be fixed in a JDK 7 update. -Abhinay. On Mar 12, 2013, at 3:13 PM, Petr Pchelko wrote: >> Hi, Petr >> I assume in jdk 7 it could be fixed too? > > The fix is very simple, I suppose it would be applicable to the jdk7. > > With best regards. Petr. > > 12.03.2013, ? 23:05, Sergey Bylokhov ???????(?): > >> Hi, Abhinay. >> Thanks for your report! >> Your bug is a duplicate of 8005997, which was fixed in jdk 8. >> http://bugs.sun.com/view_bug.do?bug_id=8005997 >> >> Hi, Petr >> I assume in jdk 7 it could be fixed too? >> >> 12.03.2013 22:41, Abhinay Reddyreddy wrote: >>> I have noticed a bug in Java 7 print dialog on Mac. I have reported it to bugs.sun.com but did not receive any response. >>> Could someone confirm if this bug has been noticed and fixed or if there is any workaround for it. >>> >>> Thanks, >>> Abhinay. >>> >>> Issue: An extra window is created at the top-left corner of the screen, if a user switches the app while it is showing a native print dialog. >>> >>> Steps to reproduce: >>> Run the attached code >>> click print button >>> when the native print dialog shows up, switch to a different app using Cmd+Tab or mouse >>> switch back to the java app with print dialog >>> notice a new window is created at the top right corner of the screen. >>> >>> java -version >>> java version "1.7.0_13" >>> Java(TM) SE Runtime Environment (build 1.7.0_13-b20) >>> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) >>> >>> >>> import javax.swing.SwingUtilities; >>> import java.awt.FlowLayout; >>> import java.awt.event.ActionEvent; >>> import java.awt.event.ActionListener; >>> import java.awt.print.PrinterJob; >>> import javax.print.attribute.HashPrintRequestAttributeSet; >>> import javax.print.attribute.PrintRequestAttributeSet; >>> import javax.print.attribute.standard.DialogTypeSelection; >>> import javax.swing.JButton; >>> import javax.swing.JFrame; >>> import java.awt.print.PrinterException; >>> >>> public class PrintDialogTestCase extends JFrame { >>> public PrintDialogTestCase() { >>> this.setTitle("Example"); >>> this.setSize(200, 100); >>> this.setLocationRelativeTo(null); >>> this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>> >>> this.setLayout(new FlowLayout()); >>> >>> JButton printDialogButton = new JButton("Print Dialog"); >>> printDialogButton.addActionListener(new ActionListener() { >>> public void actionPerformed(ActionEvent event) { >>> final PrintRequestAttributeSet attributes = new HashPrintRequestAttributeSet(); >>> attributes.add(DialogTypeSelection.NATIVE); >>> PrinterJob printJob = PrinterJob.getPrinterJob(); >>> if(printJob.printDialog(attributes)) >>> { >>> try { >>> printJob.print(); >>> } catch (PrinterException pe) { >>> } >>> } >>> >>> } >>> }); >>> this.add(printDialogButton); >>> >>> JButton exitButton = new JButton("Exit"); >>> exitButton.addActionListener(new ActionListener() { >>> public void actionPerformed(ActionEvent event) { >>> System.exit(0); >>> } >>> }); >>> this.add(exitButton); >>> } >>> public static void main(String[] args) { >>> SwingUtilities.invokeLater(new Runnable() { >>> @Override >>> public void run() { >>> PrintDialogTestCase window = new PrintDialogTestCase(); >>> window.setVisible(true); >>> } >>> }); >>> >>> } >>> } >>> >> >> >> -- >> Best regards, Sergey. >> > From alexandr.scherbatiy at oracle.com Wed Mar 13 05:41:35 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 13 Mar 2013 16:41:35 +0400 Subject: [8] Request for review: 8000435: [macosx] Button painting error under Java 7 on Mac In-Reply-To: <513F6C66.40306@oracle.com> References: <513F6C66.40306@oracle.com> Message-ID: <514073FF.6000008@oracle.com> The fix looks good for me. Is it possible to write a test on it? Thanks, Alexandr. On 3/12/2013 9:56 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk 8. Fix will be ported to jdk7 as well. > This is a tweak of the code which mimic some macosx constant. > The problem was in the assumption that we can paint native buttons > with the height of >=18 pixel(28 - 5 - 5 ), but currently it should be > >=24(28 - 2 - 2). > > In AquaButtonExtendedTypes constants in alterInsets() were changed to > be less strict. > http://cr.openjdk.java.net/~serb/8000435/before_segmentedRoundRect_first_small.png > > http://cr.openjdk.java.net/~serb/8000435/after_segmentedRoundRect_first_small.png > > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000435 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8000435/webrev.00/ > From Sergey.Bylokhov at oracle.com Wed Mar 13 09:14:32 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 13 Mar 2013 20:14:32 +0400 Subject: [8] Request for review: 8000435: [macosx] Button painting error under Java 7 on Mac In-Reply-To: <514073FF.6000008@oracle.com> References: <513F6C66.40306@oracle.com> <514073FF.6000008@oracle.com> Message-ID: <5140A5E8.2030508@oracle.com> Hi, Alexander. 13.03.2013 16:41, Alexander Scherbatiy wrote: > > The fix looks good for me. > > Is it possible to write a test on it? It is not easy, since we cannot get information about how it should look. > > Thanks, > Alexandr. > -- Best regards, Sergey. From landonf at plausible.coop Thu Mar 14 19:06:49 2013 From: landonf at plausible.coop (Landon Fuller) Date: Thu, 14 Mar 2013 22:06:49 -0400 Subject: Mac OS X Kerberos SCDynamicStore Message-ID: Howdy, I've been working a bit with Kerberos on Mac OS X, and ran into an issue with krb5.conf handling. Back in 2011, changeset 0785fa5940f6 introduced some changes to how the system kerberos configuration is handled on Mac OS X: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/0785fa5940f6 There were a few issues with this changeset, which I'll address in order: 1) No longer falls back to krb5.conf On modern Mac OS X, the various kerberos libraries consult the dynamic configuration from SCDynamicStore, and fall back on parsing the krb5.conf. As far as I'm aware, if you're not using Apple's OpenDirectory, or Microsoft ActiveDirectory, krb5.conf is the only supported way to configure system-wide kerberos behavior -- the SCDynamicStore's contents are undocumented AFAIK and effectively opaque: In the revision referenced above, the krb5.conf fallback handling was disabled on Mac OS X Lion and later releases, and instead *only* the SCDynamicStore is used: 731 } else if (osname.startsWith("Mac")) { 732 if (isLionOrBetter()) return ""; 733 name = findMacosConfigFile(); 734 } It would seem that this should be modified to re-instate the krb5.conf parsing in the case that SCDynamicStore fails to return a default realm. 2) Spurious output to stderr Additionally, the SCDynamicStoreConfig.m implementation actually prints out an error message to stderr in the case where it cannot find a default domain. Since this is actually non-error behavior, this printing seems extraneous. This seems to have been raised previously be Weijun Wang: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003490.html ... and seems to have impacted some third-party software: https://www.google.com/search?q="Unable+to+load+realm+info+from+SCDynamicStore" 3) Use of SPI I hesitated to include this last one, but ultimately I figured it's at least worth bringing up. As far as I know -- and from what I've confirmed with contacts at Apple -- the specific contents of the SCDynamicStore (including the 'Kerberos-Default-Realms' keys et al used by the Java code contributed by Apple) are considered SPI. The corresponding Heimdal headers from Apple states: "SPI constants for OD/Heimdal communication for default realm and location data using SystemConfiguration. This is a private interface and can change any time." http://www.opensource.apple.com/source/Heimdal/Heimdal-172.18/lib/krb5/HeimdalSystemConfiguration.h I don't know what the project norms are for this sort of thing, and I can't see any other way to accomplish this, so I figured I'd just mention it. The public kerberos APIs do provide access to the default realm name, but they don't (as far as I can see -- perhaps someone else will know better) provide access to the other [libdefaults] configuration values that are required. 4) Conclusion If you've made it this far, congratulations. I don't know if anyone is specifically responsible for the area in question, or if anyone has direction on an appropriate resolution. I can fairly easily resolve #1 and #2, and submit a patch. Coming from the BSD port, I also don't actually know if I have commit privileges on the Mac OS X port and wouldn't know proper procedures if I did :) Currently I'm listed as an 'author': http://openjdk.java.net/census#landonf Thanks, Landon From weijun.wang at oracle.com Thu Mar 14 19:41:13 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 15 Mar 2013 10:41:13 +0800 Subject: Mac OS X Kerberos SCDynamicStore In-Reply-To: References: Message-ID: <51428A49.1090605@oracle.com> On 3/15/13 10:06 AM, Landon Fuller wrote: > Howdy, > > I've been working a bit with Kerberos on Mac OS X, and ran into an issue with krb5.conf handling. Back in 2011, changeset 0785fa5940f6 introduced some changes to how the system kerberos configuration is handled on Mac OS X: > http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/0785fa5940f6 > > There were a few issues with this changeset, which I'll address in order: > > 1) No longer falls back to krb5.conf This has been fixed in http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4c69b4d9ace. > > On modern Mac OS X, the various kerberos libraries consult the dynamic configuration from SCDynamicStore, and fall back on parsing the krb5.conf. As far as I'm aware, if you're not using Apple's OpenDirectory, or Microsoft ActiveDirectory, krb5.conf is the only supported way to configure system-wide kerberos behavior -- the SCDynamicStore's contents are undocumented AFAIK and effectively opaque: > > In the revision referenced above, the krb5.conf fallback handling was disabled on Mac OS X Lion and later releases, and instead *only* the SCDynamicStore is used: > > 731 } else if (osname.startsWith("Mac")) { > 732 if (isLionOrBetter()) return ""; > 733 name = findMacosConfigFile(); > 734 } > > It would seem that this should be modified to re-instate the krb5.conf parsing in the case that SCDynamicStore fails to return a default realm. > > 2) Spurious output to stderr This was filed http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7151062. I was waiting for someone familiar with Objective-C to do this, but maybe we can just remove those NSLog calls. > > Additionally, the SCDynamicStoreConfig.m implementation actually prints out an error message to stderr in the case where it cannot find a default domain. Since this is actually non-error behavior, this printing seems extraneous. This seems to have been raised previously be Weijun Wang: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003490.html > > ... and seems to have impacted some third-party software: > https://www.google.com/search?q="Unable+to+load+realm+info+from+SCDynamicStore" > > 3) Use of SPI Oh. > > I hesitated to include this last one, but ultimately I figured it's at least worth bringing up. As far as I know -- and from what I've confirmed with contacts at Apple -- the specific contents of the SCDynamicStore (including the 'Kerberos-Default-Realms' keys et al used by the Java code contributed by Apple) are considered SPI. The corresponding Heimdal headers from Apple states: > "SPI constants for OD/Heimdal communication for default realm and location data using SystemConfiguration. This is a private interface and can change any time." > http://www.opensource.apple.com/source/Heimdal/Heimdal-172.18/lib/krb5/HeimdalSystemConfiguration.h > > I don't know what the project norms are for this sort of thing, and I can't see any other way to accomplish this, so I figured I'd just mention it. The public kerberos APIs do provide access to the default realm name, but they don't (as far as I can see -- perhaps someone else will know better) provide access to the other [libdefaults] configuration values that are required. > > 4) Conclusion > > If you've made it this far, congratulations. I don't know if anyone is specifically responsible for the area in question, or if anyone has direction on an appropriate resolution. I can fairly easily resolve #1 and #2, and submit a patch. I'm maintaining kerberos. > > Coming from the BSD port, I also don't actually know if I have commit privileges on the Mac OS X port and wouldn't know proper procedures if I did :) Currently I'm listed as an 'author': > http://openjdk.java.net/census#landonf The macosx-port repositories are not active now, so you should directly push into other repos (say, jdk/tl). I'll see how to promote you to a comitter. BTW, I'm also making changes to SCDynamicStoreConfig.m http://mail.openjdk.java.net/pipermail/security-dev/2013-March/006909.html Thanks Max > > Thanks, > Landon > From landonf at plausible.coop Thu Mar 14 20:40:35 2013 From: landonf at plausible.coop (Landon Fuller) Date: Thu, 14 Mar 2013 23:40:35 -0400 Subject: Mac OS X Kerberos SCDynamicStore In-Reply-To: <51428A49.1090605@oracle.com> References: <51428A49.1090605@oracle.com> Message-ID: <73437DEE-BA0B-44E6-AC05-8BFE77D4D46A@plausible.coop> On Mar 14, 2013, at 10:41 PM, Weijun Wang wrote: > On 3/15/13 10:06 AM, Landon Fuller wrote: >> 1) No longer falls back to krb5.conf > > This has been fixed in http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4c69b4d9ace. Woot. Sorry I missed the later rev. >> 2) Spurious output to stderr > > This was filed http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7151062. > > I was waiting for someone familiar with Objective-C to do this, but maybe we can just remove those NSLog calls. I suppose I might qualify. Most of the usages of NSLog() there will only be triggered in unexpected circumstances, eg, the events they log should never occur outside of some sort of system failure in the SystemConfiguration framework. There are two cases where returning NULL are expected behavior (eg, not an error, there's just no registered configuration) and I don't think warrant logging in the native code: diff -r d79503c4c56f src/macosx/native/java/util/SCDynamicStoreConfig.m --- a/src/macosx/native/java/util/SCDynamicStoreConfig.m Thu Mar 14 11:29:16 2013 -0700 +++ b/src/macosx/native/java/util/SCDynamicStoreConfig.m Thu Mar 14 23:08:44 2013 -0400 @@ -183,7 +183,6 @@ CFTypeRef realms = SCDynamicStoreCopyValue(store, (CFStringRef) KERBEROS_DEFAULT_REALMS); if (realms == NULL || CFGetTypeID(realms) != CFArrayGetTypeID()) { - NSLog(@"Unable to load realm info from SCDynamicStore"); if (realms) CFRelease(realms); CFRelease(store); return NULL; @@ -192,7 +191,6 @@ CFTypeRef realmMappings = SCDynamicStoreCopyValue(store, (CFStringRef) KERBEROS_DEFAULT_REALM_MAPPINGS); if (realmMappings == NULL || CFGetTypeID(realmMappings) != CFArrayGetTypeID()) { - NSLog(@"Unable to load realm mapping info from SCDynamicStore"); if (realmMappings) CFRelease(realmMappings); CFRelease(realms); CFRelease(store); The Java side could still check something like 'sun.security.krb5.debug' and log an error if SCDynamicStoreConfig.getKerberosConfig() returns NULL, I suppose? > BTW, I'm also making changes to SCDynamicStoreConfig.m > > http://mail.openjdk.java.net/pipermail/security-dev/2013-March/006909.html For whatever it's worth -- adding a coercions for NSData and NSDate would cover the full gamut of the possible return types from SCDynamicStoreCopyValue(). All but dates and data are covered by your registered coercers (the returned CFPropertyListRef represents types of CFData, CFString, CFArray, CFDictionary, CFDate, CFBoolean, and/or CFNumber, with CFBoolean being a specialization/subclass of CFNumber). -landonf From weijun.wang at oracle.com Thu Mar 14 21:10:37 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 15 Mar 2013 12:10:37 +0800 Subject: Mac OS X Kerberos SCDynamicStore In-Reply-To: <73437DEE-BA0B-44E6-AC05-8BFE77D4D46A@plausible.coop> References: <51428A49.1090605@oracle.com> <73437DEE-BA0B-44E6-AC05-8BFE77D4D46A@plausible.coop> Message-ID: <51429F3D.2040503@oracle.com> > >>> 2) Spurious output to stderr >> >> This was filed http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7151062. >> >> I was waiting for someone familiar with Objective-C to do this, but >> maybe we can just remove those NSLog calls. > > I suppose I might qualify. Most of the usages of NSLog() there will only > be triggered in unexpected circumstances, eg, the events they log should > never occur outside of some sort of system failure in the > SystemConfiguration framework. > > There are two cases where returning NULL are expected behavior (eg, not > an error, there's just no registered configuration) and I don't think > warrant logging in the native code: > > diff -r d79503c4c56f src/macosx/native/java/util/SCDynamicStoreConfig.m > --- a/src/macosx/native/java/util/SCDynamicStoreConfig.mThu Mar 14 > 11:29:16 2013 -0700 > +++ b/src/macosx/native/java/util/SCDynamicStoreConfig.mThu Mar 14 > 23:08:44 2013 -0400 > @@ -183,7 +183,6 @@ > CFTypeRef realms = SCDynamicStoreCopyValue(store, (CFStringRef) > KERBEROS_DEFAULT_REALMS); > if (realms == NULL || CFGetTypeID(realms) != CFArrayGetTypeID()) { > - NSLog(@"Unable to load realm info from SCDynamicStore"); > if (realms) CFRelease(realms); > CFRelease(store); > return NULL; > @@ -192,7 +191,6 @@ > CFTypeRef realmMappings = SCDynamicStoreCopyValue(store, > (CFStringRef) KERBEROS_DEFAULT_REALM_MAPPINGS); > if (realmMappings == NULL || CFGetTypeID(realmMappings) != > CFArrayGetTypeID()) { > - NSLog(@"Unable to load realm mapping info from SCDynamicStore"); > if (realmMappings) CFRelease(realmMappings); > CFRelease(realms); > CFRelease(store); > > The Java side could still check something like 'sun.security.krb5.debug' > and log an error if SCDynamicStoreConfig.getKerberosConfig() returns > NULL, I suppose? Yes, I had thought there are several different places for returning NULL, so some sort of NSLog might be still useful if they can be controlled by the Java system property. But maybe SCDynamicStoreCreate should never fail? Also I think the old code has a problem. It returns empty table when Kerberos-Default-Realms and Kerberos-Domain-Realm-Mappings keys exist but are empty. On my Mac server I turn on Open Directory and then turn it off and these two keys exist there with no content. > >> BTW, I'm also making changes to SCDynamicStoreConfig.m >> >> http://mail.openjdk.java.net/pipermail/security-dev/2013-March/006909.html > > For whatever it's worth -- adding a coercions for NSData and NSDate > would cover the full gamut of the possible return types > from SCDynamicStoreCopyValue(). All but dates and data are covered by > your registered coercers (the returned CFPropertyListRef represents > types of CFData, CFString, CFArray, CFDictionary, CFDate, CFBoolean, > and/or CFNumber, with CFBoolean being a specialization/subclass of > CFNumber). Cool. Can you tell me the exact lines? I have never played with Objective-C before. Thanks Max > > -landonf > > > From christopherbrown06 at gmail.com Sat Mar 16 15:01:19 2013 From: christopherbrown06 at gmail.com (Christopher Brown) Date: Sat, 16 Mar 2013 23:01:19 +0100 Subject: JDialog content is offset underneath the title bar when using "apple.awt.documentModalSheet" Message-ID: Hello, When using the Swing client property "apple.awt.documentModalSheet" on JDK 1.7.0_17 on a Mountain Lion Retina MacBook Pro, the dialog is the expected size but the content is offset (moved up under the title bar) and hidden/clipped. When this property is not set, the layout is as expected. The "sheet" dialog behavior is not present as it was in Apple JDK 6. I don't know if it is planned to fully implement it. However, it appears that this property is still taken into account by Oracle JDK 7 to offset the content, but because the title bar's still there, it leads to layout issues. I didn't find any reference to this issue on the bug database or by searching on the Internet. Is this the correct place to raise the issue? Thanks, Christopher From anthony.petrov at oracle.com Mon Mar 18 06:24:29 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 18 Mar 2013 17:24:29 +0400 Subject: JDialog content is offset underneath the title bar when using "apple.awt.documentModalSheet" In-Reply-To: References: Message-ID: <5147158D.1000706@oracle.com> Hi Christopher, This looks like an issue in Oracle JDK. I filed a bug for you: http://bugs.sun.com/view_bug.do?bug_id=8010197 (should be available in a day or two). -- best regards, Anthony On 03/17/13 02:01, Christopher Brown wrote: > Hello, > > When using the Swing client property "apple.awt.documentModalSheet" on JDK > 1.7.0_17 on a Mountain Lion Retina MacBook Pro, the dialog is the expected > size but the content is offset (moved up under the title bar) and > hidden/clipped. When this property is not set, the layout is as expected. > > The "sheet" dialog behavior is not present as it was in Apple JDK 6. I > don't know if it is planned to fully implement it. However, it appears > that this property is still taken into account by Oracle JDK 7 to offset > the content, but because the title bar's still there, it leads to layout > issues. > > I didn't find any reference to this issue on the bug database or by > searching on the Internet. Is this the correct place to raise the issue? > > Thanks, > Christopher From christopherbrown06 at gmail.com Mon Mar 18 08:07:55 2013 From: christopherbrown06 at gmail.com (Christopher Brown) Date: Mon, 18 Mar 2013 16:07:55 +0100 Subject: JDialog content is offset underneath the title bar when using "apple.awt.documentModalSheet" In-Reply-To: <5147158D.1000706@oracle.com> References: <5147158D.1000706@oracle.com> Message-ID: Hi Anthony, I have some screenshots but I suspect they won't get through on the mailing list. Are they helpful? Thanks, Christopher On 18 March 2013 14:24, Anthony Petrov wrote: > Hi Christopher, > > This looks like an issue in Oracle JDK. I filed a bug for you: > http://bugs.sun.com/view_bug.**do?bug_id=8010197 > (should be available in a day or two). > > -- > best regards, > Anthony > > > On 03/17/13 02:01, Christopher Brown wrote: > >> Hello, >> >> When using the Swing client property "apple.awt.documentModalSheet" on JDK >> 1.7.0_17 on a Mountain Lion Retina MacBook Pro, the dialog is the expected >> size but the content is offset (moved up under the title bar) and >> hidden/clipped. When this property is not set, the layout is as expected. >> >> The "sheet" dialog behavior is not present as it was in Apple JDK 6. I >> don't know if it is planned to fully implement it. However, it appears >> that this property is still taken into account by Oracle JDK 7 to offset >> the content, but because the title bar's still there, it leads to layout >> issues. >> >> I didn't find any reference to this issue on the bug database or by >> searching on the Internet. Is this the correct place to raise the issue? >> >> Thanks, >> Christopher >> > From anthony.petrov at oracle.com Mon Mar 18 10:33:33 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 18 Mar 2013 21:33:33 +0400 Subject: JDialog content is offset underneath the title bar when using "apple.awt.documentModalSheet" In-Reply-To: References: <5147158D.1000706@oracle.com> Message-ID: <51474FED.2030205@oracle.com> (also copying awt-dev@) Not really. The problem is obvious, and the solution is clear. Now it's just a question of resources availability. So, if anyone wants to contribute a patch - you're very welcome. But thanks anyway. And thanks for the bug report. -- best regards, Anthony On 3/18/2013 19:07, Christopher Brown wrote: > Hi Anthony, > > I have some screenshots but I suspect they won't get through on the > mailing list. Are they helpful? > > Thanks, > Christopher > > > > On 18 March 2013 14:24, Anthony Petrov > wrote: > > Hi Christopher, > > This looks like an issue in Oracle JDK. I filed a bug for you: > http://bugs.sun.com/view_bug.__do?bug_id=8010197 > > (should be available in a day or two). > > -- > best regards, > Anthony > > > On 03/17/13 02:01, Christopher Brown wrote: > > Hello, > > When using the Swing client property > "apple.awt.documentModalSheet" on JDK > 1.7.0_17 on a Mountain Lion Retina MacBook Pro, the dialog is > the expected > size but the content is offset (moved up under the title bar) and > hidden/clipped. When this property is not set, the layout is as > expected. > > The "sheet" dialog behavior is not present as it was in Apple > JDK 6. I > don't know if it is planned to fully implement it. However, it > appears > that this property is still taken into account by Oracle JDK 7 > to offset > the content, but because the title bar's still there, it leads > to layout > issues. > > I didn't find any reference to this issue on the bug database or by > searching on the Internet. Is this the correct place to raise > the issue? > > Thanks, > Christopher > > From christopherbrown06 at gmail.com Tue Mar 19 13:38:24 2013 From: christopherbrown06 at gmail.com (Christopher Brown) Date: Tue, 19 Mar 2013 21:38:24 +0100 Subject: JDialog content is offset underneath the title bar when using "apple.awt.documentModalSheet" In-Reply-To: <5147158D.1000706@oracle.com> References: <5147158D.1000706@oracle.com> Message-ID: Hello again Anthony, More generally, with regard to the various Apple-specific client properties for Swing, is there a reference document listing which ones are planned to be (or already are) supported in the Oracle / OpenJDK implementation? I assumed it could be on the project status page but couldn't find it. I certainly hope as many as possible will be supported, I found the technique was a clean way to provide extra platform-specific polish without going against cross-platform compatibility. I would be interested in testing them out (which is why I wondered if there's a reference document, to avoid indicating bugs with features that may have been dropped). Thanks, Christopher On 18 March 2013 14:24, Anthony Petrov wrote: > Hi Christopher, > > This looks like an issue in Oracle JDK. I filed a bug for you: > http://bugs.sun.com/view_bug.**do?bug_id=8010197 > (should be available in a day or two). > > -- > best regards, > Anthony > > > On 03/17/13 02:01, Christopher Brown wrote: > >> Hello, >> >> When using the Swing client property "apple.awt.documentModalSheet" on JDK >> 1.7.0_17 on a Mountain Lion Retina MacBook Pro, the dialog is the expected >> size but the content is offset (moved up under the title bar) and >> hidden/clipped. When this property is not set, the layout is as expected. >> >> The "sheet" dialog behavior is not present as it was in Apple JDK 6. I >> don't know if it is planned to fully implement it. However, it appears >> that this property is still taken into account by Oracle JDK 7 to offset >> the content, but because the title bar's still there, it leads to layout >> issues. >> >> I didn't find any reference to this issue on the bug database or by >> searching on the Internet. Is this the correct place to raise the issue? >> >> Thanks, >> Christopher >> > From paul_t100 at fastmail.fm Tue Mar 19 14:06:05 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 19 Mar 2013 21:06:05 +0000 Subject: JDialog content is offset underneath the title bar when using "apple.awt.documentModalSheet" In-Reply-To: References: <5147158D.1000706@oracle.com> Message-ID: <5148D33D.1080203@fastmail.fm> On 19/03/2013 20:38, Christopher Brown wrote: > Hello again Anthony, > > More generally, with regard to the various Apple-specific client properties > for Swing, is there a reference document listing which ones are planned to > be (or already are) supported in the Oracle / OpenJDK implementation? I > assumed it could be on the project status page but couldn't find it. > > I certainly hope as many as possible will be supported, I found the > technique was a clean way to provide extra platform-specific polish without > going against cross-platform compatibility. I would be interested in > testing them out (which is why I wondered if there's a reference document, > to avoid indicating bugs with features that may have been dropped). > > Thanks, > Christopher > Christioper I think they are all there in the current development release build 1.7.0_12-ea-b08 Paul > On 18 March 2013 14:24, Anthony Petrov wrote: > >> Hi Christopher, >> >> This looks like an issue in Oracle JDK. I filed a bug for you: >> http://bugs.sun.com/view_bug.**do?bug_id=8010197 >> (should be available in a day or two). >> >> -- >> best regards, >> Anthony >> >> >> On 03/17/13 02:01, Christopher Brown wrote: >> >>> Hello, >>> >>> When using the Swing client property "apple.awt.documentModalSheet" on JDK >>> 1.7.0_17 on a Mountain Lion Retina MacBook Pro, the dialog is the expected >>> size but the content is offset (moved up under the title bar) and >>> hidden/clipped. When this property is not set, the layout is as expected. >>> >>> The "sheet" dialog behavior is not present as it was in Apple JDK 6. I >>> don't know if it is planned to fully implement it. However, it appears >>> that this property is still taken into account by Oracle JDK 7 to offset >>> the content, but because the title bar's still there, it leads to layout >>> issues. >>> >>> I didn't find any reference to this issue on the bug database or by >>> searching on the Internet. Is this the correct place to raise the issue? >>> >>> Thanks, >>> Christopher >>> From anthony.petrov at oracle.com Wed Mar 20 04:15:49 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 20 Mar 2013 15:15:49 +0400 Subject: JDialog content is offset underneath the title bar when using "apple.awt.documentModalSheet" In-Reply-To: References: <5147158D.1000706@oracle.com> Message-ID: <51499A65.20703@oracle.com> Hi Christopher, I don't think we've ever compiled such a list. However, I'm sure that Oracle JDK should be able to support all the platform-specific features that Apple JDK supports. Please report separate bugs if you find a feature missing/not working properly in Oracle JDK. -- best regards, Anthony On 3/20/2013 0:38, Christopher Brown wrote: > Hello again Anthony, > > More generally, with regard to the various Apple-specific client > properties for Swing, is there a reference document listing which ones > are planned to be (or already are) supported in the Oracle / OpenJDK > implementation? I assumed it could be on the project status page but > couldn't find it. > > I certainly hope as many as possible will be supported, I found the > technique was a clean way to provide extra platform-specific polish > without going against cross-platform compatibility. I would be > interested in testing them out (which is why I wondered if there's a > reference document, to avoid indicating bugs with features that may have > been dropped). > > Thanks, > Christopher > > > On 18 March 2013 14:24, Anthony Petrov > wrote: > > Hi Christopher, > > This looks like an issue in Oracle JDK. I filed a bug for you: > http://bugs.sun.com/view_bug.__do?bug_id=8010197 > > (should be available in a day or two). > > -- > best regards, > Anthony > > > On 03/17/13 02:01, Christopher Brown wrote: > > Hello, > > When using the Swing client property > "apple.awt.documentModalSheet" on JDK > 1.7.0_17 on a Mountain Lion Retina MacBook Pro, the dialog is > the expected > size but the content is offset (moved up under the title bar) and > hidden/clipped. When this property is not set, the layout is as > expected. > > The "sheet" dialog behavior is not present as it was in Apple > JDK 6. I > don't know if it is planned to fully implement it. However, it > appears > that this property is still taken into account by Oracle JDK 7 > to offset > the content, but because the title bar's still there, it leads > to layout > issues. > > I didn't find any reference to this issue on the bug database or by > searching on the Internet. Is this the correct place to raise > the issue? > > Thanks, > Christopher > > From jfinley at tech4learning.com Wed Mar 20 13:30:05 2013 From: jfinley at tech4learning.com (Jessica Finley) Date: Wed, 20 Mar 2013 14:30:05 -0600 Subject: Printing in Sandbox Message-ID: Hiya, It appears that trying to print, even using the standard native dialog, causes a sandbox violation - in both JDK 7 and JDK 8. Below is a sample class which needs to be bundled into a sandboxed app to show the problem (kudos to Abhinay as this is just a slight modification of his print code submitted a few days ago). The violation occurs after you dismiss the native print dialog by pressing its Print button. I've also noticed that if you then let the app run untouched while, for example, you type up an email, it continues to throw sandbox violations of the same nature. Is there something I'm missing? I do have the com.apple.security.print entitlement set to true? This seems like a nasty bug? -Jess import java.awt.FlowLayout; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.awt.print.PrinterException; import java.awt.print.PrinterJob; import javax.print.attribute.HashPrintRequestAttributeSet; import javax.print.attribute.PrintRequestAttributeSet; import javax.print.attribute.standard.DialogTypeSelection; import javax.swing.JButton; import javax.swing.JFrame; import javax.swing.SwingUtilities; public class PrintDialogTestCase extends JFrame { public PrintDialogTestCase() { this.setTitle("Example"); this.setSize(200, 100); this.setLocationRelativeTo(null); this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); this.setLayout(new FlowLayout()); JButton printDialogButton = new JButton("Print Dialog"); printDialogButton.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent event) { PrinterJob printJob = PrinterJob.getPrinterJob(); if(printJob.printDialog()) { //don't even need to actually print, //try { //printJob.print(); //} catch (PrinterException pe) { //} } } }); this.add(printDialogButton); JButton exitButton = new JButton("Exit"); exitButton.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent event) { System.exit(0); } }); this.add(exitButton); } public static void main(String[] args) { SwingUtilities.invokeLater(new Runnable() { public void run() { PrintDialogTestCase window = new PrintDialogTestCase(); window.setVisible(true); } }); } } From mikhail.cherkasov at oracle.com Thu Mar 21 09:54:20 2013 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 21 Mar 2013 20:54:20 +0400 Subject: pasteboard update with CEmbeddedFrame Message-ID: <514B3B3C.4050402@oracle.com> Hi all, Applets doesn't see pasteboard updates at all, because AWT checks pasteboard for new data only when receives NSApplicationDidBecomeActiveNotification notification, but if we have no windows, system won't deliver this message( actually it won't deliver any NSApplication*Notification notification ). So a applet that doesn't create windows and just adds content to applet ContentPane won't able get data from pasteboard. How does jdk6 handle this? Can someone advise how to fix this? I've attached test. Steps to reproduce: 1. Unpack attached zip file. 2. copy signed jar, D.jar and Test.html to docs directory of web server. 3. Launch http://localhost/test.html 4. In the applet copy all the text into the clipboard using Cmd+c 5. Copy some text from any other application. 6. paste text to applet - awt will pastes the text that was copied previosly form applet and will ignore data form step 5. Thanks, Mikhail. From Abhinay.Reddyreddy at mathworks.com Thu Mar 21 11:41:21 2013 From: Abhinay.Reddyreddy at mathworks.com (Abhinay Reddyreddy) Date: Thu, 21 Mar 2013 18:41:21 +0000 Subject: pasteboard update with CEmbeddedFrame In-Reply-To: <514B3B3C.4050402@oracle.com> Message-ID: <353D880645CCDC429732D7A445F7F5BF4627FA67@exmb-00-ah.ad.mathworks.com> We have seen a similar problem in our software even with JDK 6. we show native windows in a Java application. Anything copied in the native window will not paste into a java window, because switching windows within the app does not trigger the notification. It would be awesome if there is a workaround for this issue. Thanks, Abhinay. On 3/21/13 12:54 PM, "mikhail cherkasov" wrote: >Hi all, > >Applets doesn't see pasteboard updates at all, because AWT checks >pasteboard for new data only when receives >NSApplicationDidBecomeActiveNotification notification, but if we have no >windows, system won't deliver >this message( actually it won't deliver any NSApplication*Notification >notification ). >So a applet that doesn't create windows and just adds content to applet >ContentPane won't able get >data from pasteboard. > >How does jdk6 handle this? Can someone advise how to fix this? > >I've attached test. >Steps to reproduce: >1. Unpack attached zip file. >2. copy signed jar, D.jar and Test.html to docs directory of web server. >3. Launch http://localhost/test.html >4. In the applet copy all the text into the clipboard using >Cmd+c >5. Copy some text from any other application. >6. paste text to applet - awt will pastes the text that was copied >previosly form applet and will ignore >data form step 5. > >Thanks, >Mikhail. From jfinley at tech4learning.com Mon Mar 25 15:33:26 2013 From: jfinley at tech4learning.com (Jessica Finley) Date: Mon, 25 Mar 2013 16:33:26 -0600 Subject: Printing in Sandbox In-Reply-To: References: Message-ID: <4ECDDD22-0E0C-45BD-AC0D-17357C865ADE@tech4learning.com> It seems that this issue is caused by bug 7175692, judging from the crash log. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175692 Is there any hope of this bug being fixed in the near future? Has anyone else encountered this problem printing? If so, what is your work-around, if any? Thanks! -Jess Crash log of the print issue: ----------------------------------------------- Process: JavaAppLauncher [4987] Path: /Users/jfinley/T4L/./Print Violation Checker 1.8.app/Contents/MacOS/JavaAppLauncher Load Address: 0x10003c000 Identifier: com.tech4learning.Pixie Version: 4.0 (4.0) Code Type: x86_64 (Native) Parent Process: JavaAppLauncher [4985] Date/Time: 2013-03-25 13:50:22.941 -0600 OS Version: Mac OS X 10.8.3 (12D78) Report Version: 8 Thread 0: 0 libsystem_kernel.dylib 0x00007fff926bb02a __open_nocancel + 10 1 libjava.dylib 0x0000000100f06d50 Java_java_lang_UNIXProcess_forkAndExec + 1369 2 0x0000000101755734 3 0x00000001017491d4 4 0x0000000101749058 5 0x0000000101749233 6 0x0000000101749233 7 0x0000000101749233 8 0x0000000101749233 9 0x00000001017434f7 10 libjvm.dylib 0x00000001004d8a8c JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 11 libjvm.dylib 0x00000001005120ab JVM_DoPrivileged + 568 Binary Images: 0x100235000 - 0x10094dfe7 libjvm.dylib (0) /Users/jfinley/T4L/Print Violation Checker 1.8.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre//lib/server/libjvm.dylib 0x100efe000 - 0x100f20fff libjava.dylib (1) /Users/jfinley/T4L/Print Violation Checker 1.8.app/Contents/PlugIns/1.7.0.jre/Contents/Home/jre/lib/libjava.dylib 0x7fff926a9000 - 0x7fff926c4ff7 libsystem_kernel.dylib (2050.22.13) <5A961E2A-CFB8-362B-BC43-122704AEB047> /usr/lib/system/libsystem_kernel.dylib On Mar 20, 2013, at 2:30 PM, Jessica Finley wrote: > Hiya, > > It appears that trying to print, even using the standard native dialog, causes a sandbox violation - in both JDK 7 and JDK 8. Below is a sample class which needs to be bundled into a sandboxed app to show the problem (kudos to Abhinay as this is just a slight modification of his print code submitted a few days ago). > > The violation occurs after you dismiss the native print dialog by pressing its Print button. > > I've also noticed that if you then let the app run untouched while, for example, you type up an email, it continues to throw sandbox violations of the same nature. > > Is there something I'm missing? I do have the com.apple.security.print entitlement set to true? This seems like a nasty bug? > > -Jess > > import java.awt.FlowLayout; > import java.awt.event.ActionEvent; > import java.awt.event.ActionListener; > import java.awt.print.PrinterException; > import java.awt.print.PrinterJob; > > import javax.print.attribute.HashPrintRequestAttributeSet; > import javax.print.attribute.PrintRequestAttributeSet; > import javax.print.attribute.standard.DialogTypeSelection; > import javax.swing.JButton; > import javax.swing.JFrame; > import javax.swing.SwingUtilities; > > public class PrintDialogTestCase extends JFrame { > public PrintDialogTestCase() { > this.setTitle("Example"); > this.setSize(200, 100); > this.setLocationRelativeTo(null); > this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > > this.setLayout(new FlowLayout()); > > JButton printDialogButton = new JButton("Print Dialog"); > printDialogButton.addActionListener(new ActionListener() { > public void actionPerformed(ActionEvent event) { > PrinterJob printJob = PrinterJob.getPrinterJob(); > if(printJob.printDialog()) > { > //don't even need to actually print, > //try { > //printJob.print(); > //} catch (PrinterException pe) { > //} > } > > } > }); > this.add(printDialogButton); > > JButton exitButton = new JButton("Exit"); > exitButton.addActionListener(new ActionListener() { > public void actionPerformed(ActionEvent event) { > System.exit(0); > } > }); > this.add(exitButton); > } > public static void main(String[] args) { > SwingUtilities.invokeLater(new Runnable() { > public void run() { > PrintDialogTestCase window = new PrintDialogTestCase(); > window.setVisible(true); > } > }); > } > } > > From Sergey.Bylokhov at oracle.com Tue Mar 26 08:33:30 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Mar 2013 19:33:30 +0400 Subject: [8] Request for review: 8000629 [macosx] Blurry rendering with Java 7 on Retina display Message-ID: <5151BFCA.1060702@oracle.com> Hello, Please review the fix for jdk 8. Change adds initial support of hidpi(mostly on 2d side). In the fix scale was added to the surface data/CGraphicsDevice /CGLLayer. This scale factor maps virtual coordinates to physical pixels. This change doesn't add support of hidpi to aqua l&f and doesn't add support of dynamic change of scale factor. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629 Webrev can be found at: http://cr.openjdk.java.net/~serb/8000629/webrev.06 -- Best regards, Sergey. From dan.xu at oracle.com Tue Mar 26 17:19:00 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 26 Mar 2013 17:19:00 -0700 Subject: How to Run PrimitiveCoder.hs Message-ID: <51523AF4.3000405@oracle.com> Hi, I wonder whether anyone happens to know how to run jdk/src/macosx/native/jobjc/src/core/PrimitiveCoder.hs to generate java code. It seems that macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java is generated by this script. I am currently working on a bug where I need to change this script file, PrimitiveCoder.hs. And I want to run it manually to verify my modification. Thanks! -Dan From dbp at stanford.edu Tue Mar 26 17:22:45 2013 From: dbp at stanford.edu (Dave Barker-Plummer) Date: Tue, 26 Mar 2013 17:22:45 -0700 Subject: Support for com.apple.eawt in Java 1.7 Message-ID: <9D89FAF5-282C-4006-B605-C736217DC4BB@stanford.edu> Is it intended that the port of java 1.7 for Mac OS X will support the extensions previously in com.apple.eawt? How about apple's custom system properties relating to component styles? -- Dave From Sergey.Bylokhov at oracle.com Wed Mar 27 01:19:27 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 27 Mar 2013 12:19:27 +0400 Subject: Support for com.apple.eawt in Java 1.7 In-Reply-To: <9D89FAF5-282C-4006-B605-C736217DC4BB@stanford.edu> References: <9D89FAF5-282C-4006-B605-C736217DC4BB@stanford.edu> Message-ID: <5152AB8F.2070609@oracle.com> Hi, Dave. Most of them should work in jdk8 and jdk7u-dev and if doesn't work you should file the CR: http://bugs.sun.com. On 3/27/13 4:22 AM, Dave Barker-Plummer wrote: > Is it intended that the port of java 1.7 for Mac OS X will support the extensions previously in com.apple.eawt? How about apple's custom system properties relating to component styles? > > -- Dave -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Mar 27 07:52:27 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 27 Mar 2013 18:52:27 +0400 Subject: [8] Request for review: 8000629 [macosx] Blurry rendering with Java 7 on Retina display In-Reply-To: <5151BFCA.1060702@oracle.com> References: <5151BFCA.1060702@oracle.com> Message-ID: <515307AB.7080208@oracle.com> Hi Sergey, src/macosx/classes/sun/java2d/opengl/CGLLayer.java > 48 private int scale = 1; src/macosx/classes/sun/awt/CGraphicsDevice.java > 222 public int getScaleFactor() { src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java > 45 protected final int scale; (there's also other usages of int in shared code) Why do we use integer values here? There's no 100% guarantee that the scale factor is integer on Mac (or other platforms when we support HiDPI rendering on them). At least native APIs operate with float values. Also, I wonder if we have to maintain the double precision for the scale factor in native functions nativeSetScale/nativeGetScaleFactor (and in Region.java, too). Would float values work fine? src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java > 444 //Temporary disable this logic and use some magic constrain. > 457 return getMaxTextureSize() / (getDevice().getScaleFactor() * 2); I believe that this workaround is unrelated to the core retina-support fix and should be omitted from it. -- best regards, Anthony On 3/26/2013 19:33, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk 8. > Change adds initial support of hidpi(mostly on 2d side). In the fix > scale was added to the surface data/CGraphicsDevice /CGLLayer. This > scale factor maps virtual coordinates to physical pixels. > This change doesn't add support of hidpi to aqua l&f and doesn't add > support of dynamic change of scale factor. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8000629/webrev.06 > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Wed Mar 27 08:15:19 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 27 Mar 2013 19:15:19 +0400 Subject: [8] Request for review: 8000629 [macosx] Blurry rendering with Java 7 on Retina display In-Reply-To: <5152E219.5040609@oracle.com> References: <5151BFCA.1060702@oracle.com> <5152E219.5040609@oracle.com> Message-ID: <51530D07.1060107@oracle.com> On 3/27/13 4:12 PM, Denis S. Fokin wrote: > Hi Sergey, > > why we do not use Math.round() here? > Region.java: > 153 return (int) Math.floor(newv + 0.5); Just because it one additional call. > > Thank you, > Denis. > > > On 3/26/2013 7:33 PM, Sergey Bylokhov wrote: >> Hello, >> Please review the fix for jdk 8. >> Change adds initial support of hidpi(mostly on 2d side). In the fix >> scale was added to the surface data/CGraphicsDevice /CGLLayer. This >> scale factor maps virtual coordinates to physical pixels. >> This change doesn't add support of hidpi to aqua l&f and doesn't add >> support of dynamic change of scale factor. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8000629/webrev.06 >> >> -- >> Best regards, Sergey. >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Mar 27 09:12:09 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 27 Mar 2013 20:12:09 +0400 Subject: [8] Request for review: 8000629 [macosx] Blurry rendering with Java 7 on Retina display In-Reply-To: <515307AB.7080208@oracle.com> References: <5151BFCA.1060702@oracle.com> <515307AB.7080208@oracle.com> Message-ID: <51531A59.80002@oracle.com> On 3/27/13 6:52 PM, Anthony Petrov wrote: > (there's also other usages of int in shared code) > Why do we use integer values here? There's no 100% guarantee that the > scale factor is integer on Mac (or other platforms when we support > HiDPI rendering on them). At least native APIs operate with float values. Yes, but it is unclear how we could convert points to pixels when the scale factor of 1.5, for example. If we get xx.xx scale in the future, additional work will be required. For now the simplest way just used. > > Also, I wonder if we have to maintain the double precision for the > scale factor in native functions nativeSetScale/nativeGetScaleFactor > (and in Region.java, too). Would float values work fine? I use double precision everywhere, because SunGraphics2D in the transform uses double precision, and I cast double to int where it is safe. > > > src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java >> 444 //Temporary disable this logic and use some magic >> constrain. >> 457 return getMaxTextureSize() / >> (getDevice().getScaleFactor() * 2); > > I believe that this workaround is unrelated to the core retina-support > fix and should be omitted from it. Without this change, applets unsuitable for use in hidpi mode under quartz-debug(our sqe use it also). Moreover I assume, that the display bounds constrain is incorrect anyway. > > -- > best regards, > Anthony > > On 3/26/2013 19:33, Sergey Bylokhov wrote: >> Hello, >> Please review the fix for jdk 8. >> Change adds initial support of hidpi(mostly on 2d side). In the fix >> scale was added to the surface data/CGraphicsDevice /CGLLayer. This >> scale factor maps virtual coordinates to physical pixels. >> This change doesn't add support of hidpi to aqua l&f and doesn't add >> support of dynamic change of scale factor. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8000629/webrev.06 >> >> -- >> Best regards, Sergey. -- Best regards, Sergey. From jcpalmer at rochester.rr.com Wed Mar 27 12:41:47 2013 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Wed, 27 Mar 2013 15:41:47 -0400 Subject: JTables in JScrollPane in top half of JSplitPane Message-ID: <76A8A0B7-EA55-41A2-8093-C3388222D1DA@rochester.rr.com> Such a JTable in Mac OSX starts appearing with the header half chopped off, but not on Win7. Was wondering if this is in the Bug DB? Do not know how to query DB. Since this is just in a private backend client, I avoid running this on Mac. Do not want to make a test case only to find the bug is a duplicate, as I have actually made a sub-class of JScrollPane, and have 2 JTables (one in the Viewport & the other in the rowHeader). A very clean test case including data would be a lot of labor. Again is this a known bug? Thanks, Jeff Palmer From leonid.romanov at oracle.com Wed Mar 27 10:06:00 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 27 Mar 2013 21:06:00 +0400 Subject: JTables in JScrollPane in top half of JSplitPane In-Reply-To: <76A8A0B7-EA55-41A2-8093-C3388222D1DA@rochester.rr.com> References: <76A8A0B7-EA55-41A2-8093-C3388222D1DA@rochester.rr.com> Message-ID: <515326F8.4000406@oracle.com> A link to the screenshot would be nice. Leonid. On 3/27/2013 11:41 PM, Jeff Palmer wrote: > Such a JTable in Mac OSX starts appearing with the header half chopped off, but not on Win7. Was wondering if this is in the Bug DB? Do not know how to query DB. > > Since this is just in a private backend client, I avoid running this on Mac. Do not want to make a test case only to find the bug is a duplicate, as I have actually made a sub-class of JScrollPane, and have 2 JTables (one in the Viewport & the other in the rowHeader). A very clean test case including data would be a lot of labor. > > Again is this a known bug? > > Thanks, > > Jeff Palmer From jcpalmer at rochester.rr.com Wed Mar 27 14:51:08 2013 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Wed, 27 Mar 2013 17:51:08 -0400 Subject: JTables in JScrollPane in top half of JSplitPane In-Reply-To: <515326F8.4000406@oracle.com> References: <76A8A0B7-EA55-41A2-8093-C3388222D1DA@rochester.rr.com> <515326F8.4000406@oracle.com> Message-ID: Ok. Do not think this DL supports attachments though. Can put jpg on site and pass links (probably tomorrow) Jeff On Mar 27, 2013, at 1:06 PM, Leonid Romanov wrote: > A link to the screenshot would be nice. > > Leonid. > > On 3/27/2013 11:41 PM, Jeff Palmer wrote: >> Such a JTable in Mac OSX starts appearing with the header half chopped off, but not on Win7. Was wondering if this is in the Bug DB? Do not know how to query DB. >> >> Since this is just in a private backend client, I avoid running this on Mac. Do not want to make a test case only to find the bug is a duplicate, as I have actually made a sub-class of JScrollPane, and have 2 JTables (one in the Viewport & the other in the rowHeader). A very clean test case including data would be a lot of labor. >> >> Again is this a known bug? >> >> Thanks, >> >> Jeff Palmer > From leonid.romanov at oracle.com Wed Mar 27 15:21:54 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 28 Mar 2013 02:21:54 +0400 Subject: JTables in JScrollPane in top half of JSplitPane In-Reply-To: References: <76A8A0B7-EA55-41A2-8093-C3388222D1DA@rochester.rr.com> <515326F8.4000406@oracle.com> Message-ID: <83C4EED5-B4FF-45A3-9056-E598CAA1EB98@oracle.com> Yep, please do it. We already have a bug which might be related to your problem, but it is hard to say without actually seeing the screenshot. On Mar 28, 2013, at 1:51 AM, Jeff Palmer wrote: > Ok. Do not think this DL supports attachments though. Can put jpg on site and pass links (probably tomorrow) > > Jeff > > On Mar 27, 2013, at 1:06 PM, Leonid Romanov wrote: > >> A link to the screenshot would be nice. >> >> Leonid. >> >> On 3/27/2013 11:41 PM, Jeff Palmer wrote: >>> Such a JTable in Mac OSX starts appearing with the header half chopped off, but not on Win7. Was wondering if this is in the Bug DB? Do not know how to query DB. >>> >>> Since this is just in a private backend client, I avoid running this on Mac. Do not want to make a test case only to find the bug is a duplicate, as I have actually made a sub-class of JScrollPane, and have 2 JTables (one in the Viewport & the other in the rowHeader). A very clean test case including data would be a lot of labor. >>> >>> Again is this a known bug? >>> >>> Thanks, >>> >>> Jeff Palmer >> > From jcpalmer at rochester.rr.com Wed Mar 27 15:39:13 2013 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Wed, 27 Mar 2013 18:39:13 -0400 Subject: JTables in JScrollPane in top half of JSplitPane In-Reply-To: <515326F8.4000406@oracle.com> References: <76A8A0B7-EA55-41A2-8093-C3388222D1DA@rochester.rr.com> <515326F8.4000406@oracle.com> Message-ID: <4C1074EC-0BDA-46F1-9632-D6BE52BBBAD5@rochester.rr.com> here: http://www.whatifsquared.com/splitpane.png Scrollpane in top of split has header JTable (grey background) & a horizontally scrolling main JTable. Notice the column headings are almost gone. There are over 30 columns, so it is almost completely unusable like this. In bottom is a JComponent painted based on the line selected in either table above. Some times want to see more of either the data or chart, hence the split pane. Do not know what will happen if not enough rows to cause vertical scrolling. Could force it in code if it would help. Thanks, Jeff On Mar 27, 2013, at 1:06 PM, Leonid Romanov wrote: > A link to the screenshot would be nice. > > Leonid. > > On 3/27/2013 11:41 PM, Jeff Palmer wrote: >> Such a JTable in Mac OSX starts appearing with the header half chopped off, but not on Win7. Was wondering if this is in the Bug DB? Do not know how to query DB. >> >> Since this is just in a private backend client, I avoid running this on Mac. Do not want to make a test case only to find the bug is a duplicate, as I have actually made a sub-class of JScrollPane, and have 2 JTables (one in the Viewport & the other in the rowHeader). A very clean test case including data would be a lot of labor. >> >> Again is this a known bug? >> >> Thanks, >> >> Jeff Palmer > From Sergey.Bylokhov at oracle.com Thu Mar 28 02:12:46 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 28 Mar 2013 13:12:46 +0400 Subject: [8] Request for review: 8000629 [macosx] Blurry rendering with Java 7 on Retina display In-Reply-To: <5154078F.9070708@oracle.com> References: <5151BFCA.1060702@oracle.com> <5152E219.5040609@oracle.com> <51530D07.1060107@oracle.com> <5154078F.9070708@oracle.com> Message-ID: <5154098E.3000803@oracle.com> On 3/28/13 1:04 PM, Denis S. Fokin wrote: > Hi Sergey, > > actually, the round function has a little bit more complicated > implementation because of 6430675. Thanks for pointing this, I'll change the code. > > Thank you, > Denis. > > On 3/27/2013 7:15 PM, Sergey Bylokhov wrote: >> On 3/27/13 4:12 PM, Denis S. Fokin wrote: >>> Hi Sergey, >>> >>> why we do not use Math.round() here? >>> Region.java: >>> 153 return (int) Math.floor(newv + 0.5); >> Just because it one additional call. >>> >>> Thank you, >>> Denis. >>> >>> >>> On 3/26/2013 7:33 PM, Sergey Bylokhov wrote: >>>> Hello, >>>> Please review the fix for jdk 8. >>>> Change adds initial support of hidpi(mostly on 2d side). In the fix >>>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This >>>> scale factor maps virtual coordinates to physical pixels. >>>> This change doesn't add support of hidpi to aqua l&f and doesn't add >>>> support of dynamic change of scale factor. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06 >>>> >>>> -- >>>> Best regards, Sergey. >>>> >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Mar 28 04:14:18 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 28 Mar 2013 15:14:18 +0400 Subject: [8] Request for review: 8000629 [macosx] Blurry rendering with Java 7 on Retina display In-Reply-To: <5154078F.9070708@oracle.com> References: <5151BFCA.1060702@oracle.com> <5152E219.5040609@oracle.com> <51530D07.1060107@oracle.com> <5154078F.9070708@oracle.com> Message-ID: <5154260A.8020206@oracle.com> On 3/28/13 1:04 PM, Denis S. Fokin wrote: > Hi Sergey, > > actually, the round function has a little bit more complicated > implementation because of 6430675. Here is the new version: http://cr.openjdk.java.net/~serb/8000629/webrev.07 > > Thank you, > Denis. > > On 3/27/2013 7:15 PM, Sergey Bylokhov wrote: >> On 3/27/13 4:12 PM, Denis S. Fokin wrote: >>> Hi Sergey, >>> >>> why we do not use Math.round() here? >>> Region.java: >>> 153 return (int) Math.floor(newv + 0.5); >> Just because it one additional call. >>> >>> Thank you, >>> Denis. >>> >>> >>> On 3/26/2013 7:33 PM, Sergey Bylokhov wrote: >>>> Hello, >>>> Please review the fix for jdk 8. >>>> Change adds initial support of hidpi(mostly on 2d side). In the fix >>>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This >>>> scale factor maps virtual coordinates to physical pixels. >>>> This change doesn't add support of hidpi to aqua l&f and doesn't add >>>> support of dynamic change of scale factor. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06 >>>> >>>> -- >>>> Best regards, Sergey. >>>> >>> >> >> > -- Best regards, Sergey. From anthony.petrov at oracle.com Thu Mar 28 04:59:11 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 28 Mar 2013 15:59:11 +0400 Subject: [8] Request for review: 8000629 [macosx] Blurry rendering with Java 7 on Retina display In-Reply-To: <51531A59.80002@oracle.com> References: <5151BFCA.1060702@oracle.com> <515307AB.7080208@oracle.com> <51531A59.80002@oracle.com> Message-ID: <5154308F.2080602@oracle.com> On 03/27/13 20:12, Sergey Bylokhov wrote: > On 3/27/13 6:52 PM, Anthony Petrov wrote: >> (there's also other usages of int in shared code) >> Why do we use integer values here? There's no 100% guarantee that the >> scale factor is integer on Mac (or other platforms when we support >> HiDPI rendering on them). At least native APIs operate with float values. > Yes, but it is unclear how we could convert points to pixels when the > scale factor of 1.5, for example. If we get xx.xx scale in the future, > additional work will be required. For now the simplest way just used. >> >> Also, I wonder if we have to maintain the double precision for the >> scale factor in native functions nativeSetScale/nativeGetScaleFactor >> (and in Region.java, too). Would float values work fine? > I use double precision everywhere, because SunGraphics2D in the > transform uses double precision, and I cast double to int where it is safe. That makes sense. Thanks for the clarifications. >> src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java >>> 444 //Temporary disable this logic and use some magic constrain. >>> 457 return getMaxTextureSize() / (getDevice().getScaleFactor() * 2); >> >> I believe that this workaround is unrelated to the core retina-support >> fix and should be omitted from it. > Without this change, applets unsuitable for use in hidpi mode under > quartz-debug(our sqe use it also). Moreover I assume, that the display > bounds constrain is incorrect anyway. This only applies to a few specific applets, and the problem is not directly related to HiDPI support because you'll run into a similar bug when running with a LoDPI native resolution of, say, 640x480 or 800x600. Therefore I believe that this particular change deserves a separate CR. Could you file one please and remove the change from your current fix? -- best regards, Anthony >> >> -- >> best regards, >> Anthony >> >> On 3/26/2013 19:33, Sergey Bylokhov wrote: >>> Hello, >>> Please review the fix for jdk 8. >>> Change adds initial support of hidpi(mostly on 2d side). In the fix >>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This >>> scale factor maps virtual coordinates to physical pixels. >>> This change doesn't add support of hidpi to aqua l&f and doesn't add >>> support of dynamic change of scale factor. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8000629/webrev.06 >>> >>> -- >>> Best regards, Sergey. > > From Sergey.Bylokhov at oracle.com Thu Mar 28 05:37:48 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 28 Mar 2013 16:37:48 +0400 Subject: [8] Request for review: 8000629 [macosx] Blurry rendering with Java 7 on Retina display In-Reply-To: <5154308F.2080602@oracle.com> References: <5151BFCA.1060702@oracle.com> <515307AB.7080208@oracle.com> <51531A59.80002@oracle.com> <5154308F.2080602@oracle.com> Message-ID: <5154399C.7000405@oracle.com> > This only applies to a few specific applets, Most of our demos just does not work, because of that I leave it here. > and the problem is not directly related to HiDPI support because > you'll run into a similar bug when running with a LoDPI native > resolution of, say, 640x480 or 800x600. Therefore I believe that this > particular change deserves a separate CR. Could you file one please > and remove the change from your current fix? Yes I'll rework it later, for now I create CR for it 8010999. > > -- > best regards, > Anthony > >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 3/26/2013 19:33, Sergey Bylokhov wrote: >>>> Hello, >>>> Please review the fix for jdk 8. >>>> Change adds initial support of hidpi(mostly on 2d side). In the fix >>>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This >>>> scale factor maps virtual coordinates to physical pixels. >>>> This change doesn't add support of hidpi to aqua l&f and doesn't add >>>> support of dynamic change of scale factor. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06 >>>> >>>> -- >>>> Best regards, Sergey. >> >> -- Best regards, Sergey. From anthony.petrov at oracle.com Thu Mar 28 06:10:18 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 28 Mar 2013 17:10:18 +0400 Subject: [8] Request for review: 8000629 [macosx] Blurry rendering with Java 7 on Retina display In-Reply-To: <5154399C.7000405@oracle.com> References: <5151BFCA.1060702@oracle.com> <515307AB.7080208@oracle.com> <51531A59.80002@oracle.com> <5154308F.2080602@oracle.com> <5154399C.7000405@oracle.com> Message-ID: <5154413A.5070805@oracle.com> OK. Thanks for filing the bug. -- best regards, Anthony On 03/28/13 16:37, Sergey Bylokhov wrote: > >> This only applies to a few specific applets, > Most of our demos just does not work, because of that I leave it here. >> and the problem is not directly related to HiDPI support because >> you'll run into a similar bug when running with a LoDPI native >> resolution of, say, 640x480 or 800x600. Therefore I believe that this >> particular change deserves a separate CR. Could you file one please >> and remove the change from your current fix? > Yes I'll rework it later, for now I create CR for it 8010999. >> >> -- >> best regards, >> Anthony >> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 3/26/2013 19:33, Sergey Bylokhov wrote: >>>>> Hello, >>>>> Please review the fix for jdk 8. >>>>> Change adds initial support of hidpi(mostly on 2d side). In the fix >>>>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This >>>>> scale factor maps virtual coordinates to physical pixels. >>>>> This change doesn't add support of hidpi to aqua l&f and doesn't add >>>>> support of dynamic change of scale factor. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06 >>>>> >>>>> -- >>>>> Best regards, Sergey. >>> >>> > > > -- > Best regards, Sergey. > From Vladislav.Karnaukhov at oracle.com Thu Mar 28 08:23:38 2013 From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov) Date: Thu, 28 Mar 2013 19:23:38 +0400 Subject: [8] Review request for 8010721: [macosx] In JDK7 the menu bar disappears when a Dialog is shown In-Reply-To: References: <5152F7F0.1020907@oracle.com> Message-ID: <5154607A.90301@oracle.com> Hello Leonid, all, thanks for the review and could you please review a new version: http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.01/ This version is implemented completely via JNF; I removed all changes from Java part. Regards, - Vlad On 27.03.13 18:10, Leonid Romanov wrote: > Hi, > For 1, perhaps you could use AWTWindow's javaPlatformWindow to get to corresponding LWWindowPeer, which has peerType field. > > On Mar 27, 2013, at 5:45 PM, Vladislav Karnaukhov wrote: > >> Hello, >> >> please review a fix for 8010721. >> >> bug: http://bugs.sun.com/view_bug.do?bug_id=8010721 >> webrev: http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.00/ >> >> This implementation handles a scenario when a modal dialog is shown: in this case we dim main window' menu bar items (if any). >> >> However, there are 2 issues that I'd like to discuss: >> 1. Apple JDK always hides the menu bar when a new *form* doesn't have any. My realization keeps the main form' menu bar if a new form is shown. I wasn't able to determine a way to distinguish a Frame from a Dialog: both of them are AWTWindow. >> >> 2. Could you please provide ideas for tests (if we need them here)? When a modal dialog is being shown, can we access the menu bar to check if items became dimmed? >> >> Regards, >> - Vlad From Sergey.Bylokhov at oracle.com Thu Mar 28 08:49:00 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 28 Mar 2013 19:49:00 +0400 Subject: [8] Review request for 8010721: [macosx] In JDK7 the menu bar disappears when a Dialog is shown In-Reply-To: <5154607A.90301@oracle.com> References: <5152F7F0.1020907@oracle.com> <5154607A.90301@oracle.com> Message-ID: <5154666C.3080706@oracle.com> Not sure that now it looks better. On 3/28/13 7:23 PM, Vladislav Karnaukhov wrote: > Hello Leonid, all, > > thanks for the review and could you please review a new version: > http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.01/ > > This version is implemented completely via JNF; I removed all changes > from Java part. > > Regards, > - Vlad > > On 27.03.13 18:10, Leonid Romanov wrote: >> Hi, >> For 1, perhaps you could use AWTWindow's javaPlatformWindow to get to >> corresponding LWWindowPeer, which has peerType field. >> >> On Mar 27, 2013, at 5:45 PM, Vladislav >> Karnaukhov wrote: >> >>> Hello, >>> >>> please review a fix for 8010721. >>> >>> bug: http://bugs.sun.com/view_bug.do?bug_id=8010721 >>> webrev: http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.00/ >>> >>> This implementation handles a scenario when a modal dialog is shown: >>> in this case we dim main window' menu bar items (if any). >>> >>> However, there are 2 issues that I'd like to discuss: >>> 1. Apple JDK always hides the menu bar when a new *form* doesn't >>> have any. My realization keeps the main form' menu bar if a new form >>> is shown. I wasn't able to determine a way to distinguish a Frame >>> from a Dialog: both of them are AWTWindow. >>> >>> 2. Could you please provide ideas for tests (if we need them here)? >>> When a modal dialog is being shown, can we access the menu bar to >>> check if items became dimmed? >>> >>> Regards, >>> - Vlad > -- Best regards, Sergey. From Vladislav.Karnaukhov at oracle.com Thu Mar 28 08:54:33 2013 From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov) Date: Thu, 28 Mar 2013 19:54:33 +0400 Subject: [8] Review request for 8010721: [macosx] In JDK7 the menu bar disappears when a Dialog is shown In-Reply-To: <5154666C.3080706@oracle.com> References: <5152F7F0.1020907@oracle.com> <5154607A.90301@oracle.com> <5154666C.3080706@oracle.com> Message-ID: <515467B9.2010002@oracle.com> On 28.03.13 19:49, Sergey Bylokhov wrote: > Not sure that now it looks better. Sergey, could you please clarify? Did you mean that modality check via JNF is ambiguous/redundant and it would be better to use bit field? Or do you have some other concerns? Regards, - Vlad > > > On 3/28/13 7:23 PM, Vladislav Karnaukhov wrote: >> Hello Leonid, all, >> >> thanks for the review and could you please review a new version: >> http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.01/ >> >> This version is implemented completely via JNF; I removed all changes >> from Java part. >> >> Regards, >> - Vlad >> >> On 27.03.13 18:10, Leonid Romanov wrote: >>> Hi, >>> For 1, perhaps you could use AWTWindow's javaPlatformWindow to get >>> to corresponding LWWindowPeer, which has peerType field. >>> >>> On Mar 27, 2013, at 5:45 PM, Vladislav >>> Karnaukhov wrote: >>> >>>> Hello, >>>> >>>> please review a fix for 8010721. >>>> >>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8010721 >>>> webrev: http://cr.openjdk.java.net/~vkarnauk/8010721/jdk8/webrev.00/ >>>> >>>> This implementation handles a scenario when a modal dialog is >>>> shown: in this case we dim main window' menu bar items (if any). >>>> >>>> However, there are 2 issues that I'd like to discuss: >>>> 1. Apple JDK always hides the menu bar when a new *form* doesn't >>>> have any. My realization keeps the main form' menu bar if a new >>>> form is shown. I wasn't able to determine a way to distinguish a >>>> Frame from a Dialog: both of them are AWTWindow. >>>> >>>> 2. Could you please provide ideas for tests (if we need them here)? >>>> When a modal dialog is being shown, can we access the menu bar to >>>> check if items became dimmed? >>>> >>>> Regards, >>>> - Vlad >> > > From philip.race at oracle.com Fri Mar 29 08:55:32 2013 From: philip.race at oracle.com (Phil Race) Date: Fri, 29 Mar 2013 08:55:32 -0700 Subject: [OpenJDK 2D-Dev] [8] Request for review: 8000629 [macosx] Blurry rendering with Java 7 on Retina display In-Reply-To: <5154399C.7000405@oracle.com> References: <5151BFCA.1060702@oracle.com> <515307AB.7080208@oracle.com> <51531A59.80002@oracle.com> <5154308F.2080602@oracle.com> <5154399C.7000405@oracle.com> Message-ID: <5155B974.5020607@oracle.com> I've been trying out the patch - using quartz debug, since I don't have a retina display. Aside from occasional artifacts in theSwing controls which may well be code there that doesn't handle this case well, the only pure 2D thing that I noticed was the Texture Paint demos in Java2Demo don't seem to handle this well. The textures aren't being scaled. Likely not our problem, rather quartz debug, is that if I switched display modes whilst quartz debug was running *and* we had the 2D animation running, then large parts of the display flashed, even after I quit the 2D demo. I had to quit quartz debug to get it to stop. -phil. On 3/28/2013 5:37 AM, Sergey Bylokhov wrote: > >> This only applies to a few specific applets, > Most of our demos just does not work, because of that I leave it here. >> and the problem is not directly related to HiDPI support because >> you'll run into a similar bug when running with a LoDPI native >> resolution of, say, 640x480 or 800x600. Therefore I believe that this >> particular change deserves a separate CR. Could you file one please >> and remove the change from your current fix? > Yes I'll rework it later, for now I create CR for it 8010999. >> >> -- >> best regards, >> Anthony >> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 3/26/2013 19:33, Sergey Bylokhov wrote: >>>>> Hello, >>>>> Please review the fix for jdk 8. >>>>> Change adds initial support of hidpi(mostly on 2d side). In the fix >>>>> scale was added to the surface data/CGraphicsDevice /CGLLayer. This >>>>> scale factor maps virtual coordinates to physical pixels. >>>>> This change doesn't add support of hidpi to aqua l&f and doesn't add >>>>> support of dynamic change of scale factor. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06 >>>>> >>>>> -- >>>>> Best regards, Sergey. >>> >>> > > > -- > Best regards, Sergey. From mikhail.cherkasov at oracle.com Fri Mar 29 09:03:02 2013 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Fri, 29 Mar 2013 20:03:02 +0400 Subject: Review request: 8010925: COPY AND PASTE TO AND FROM SIGNED APPLET FAILS AFTER FIRST INTERNAL COPY PRFRMD In-Reply-To: <5155B691.2000201@oracle.com> References: <5155B691.2000201@oracle.com> Message-ID: <5155BB36.9030106@oracle.com> macosx-port-dev was added. On 29.03.2013 19:43, mikhail cherkasov wrote: > Hello all, > > Could you please review the following fix: > http://bugs.sun.com/view_bug.do?bug_id=8010925 > http://cr.openjdk.java.net/~mcherkas/8010925/webrev.00/ > > > Applet doesn't receive any NSApplication*Notification because it > doesn't create any windows, so if we have applet with windows - all > works fine. > But in this case all content are added to applet's ContentPane that is > embedded to browser and hasn't any window. > But AWT updates clipboard data only on > NSApplicationDidBecameActiveNotification. > So if we make copy action from applet , applet will never read new > data from system pastboard, > it just will use cached data. > To fix this I added pasteboard check on CEmbeddedFrame focus receiving. > > Thanks, > Mikhail. >