Alexander, Since there are existing applications using com.apple.eawt and com.apple.eio internal APIs, I propose to deprecate them in JDK 9 and remove these two packages in JDK 10 to give time to existing applications to migrate to this new API.
Mandy > On Nov 24, 2015, at 7:02 AM, Alexander Zvegintsev > <alexander.zvegint...@oracle.com> wrote: > > Please review the updated fix: > http://cr.openjdk.java.net/~azvegint/jdk/9/8143227/03/ > > removed fullscreen related code (moved to JDK-8143914 [0]) > fix serialization in AppEvent > > [0] https://bugs.openjdk.java.net/browse/JDK-8143914 > > Thanks, > > Alexander. > > On 11/21/2015 03:33 AM, Alexander Zvegintsev wrote: >> Hi Phil, >> >>> Can someone explain why this is needed given the existing support of >>> GraphicsDevice.setFullScreenWindow(Window) ? >> >> GraphicsDevice.setFullScreenWindow is used for an exclusive full screen >> mode. >> Mac OS has another option to create a virtual desktop with provided window >> in it. >> You can switch between them by three-finger horizontal swipe. >> >>> Why does it have to be a RootPaneContainer ? Why is this tied to Swing ? >>> This appears to narrow it to JDialog and JWindow. >> It reuses swing code to set native windows style bits. >> >> >> Please see updated webrev: >> http://cr.openjdk.java.net/~azvegint/jdk/9/8143227/02/ >> updated permission >> added missing @throws @since and @implNote >> browseFileDirectory is now return void >> RootPaneContainer -> JDialog and JWindow >> >> -- >> Thanks, >> Alexander. >> >> On 11/20/2015 09:03 PM, Phil Race wrote: >>> On 11/20/2015 09:12 AM, Sergey Bylokhov wrote: >>>> >>>> I am worried about setWindowCanFullScreen and requestToggleFullScreen. >>>> On the latest osx this functionality was merged with maximize button. So >>>> probably it will be better to change behavior of window.setExtendedState() >>>> + MAXIMIZED_BOTH? >>> >>> Can someone explain why this is needed given the existing support of >>> GraphicsDevice.setFullScreenWindow(Window) ? >>> >>> And what happens if you use *both* ? They still need to play well together >>> if there is some reason the new one is needed. >>> >>> Other comments : >>> > * Note, Aqua Look and Feel should be active to support this on Mac OS. >>> >>> >>> Needs @implNote >>> >>> There seems to be lots of missing SecurityException tags given all the >>> checkAWTPermission() calls. >>> is checkAWTPermission() really the right call for all of these actions ? >>> Does it "cover" being able to delete files and quit the app ? I am not sure >>> it is >>> correct in all cases. >>> >>> And also there are missing @since tags. >>> >>> >>> Opens a folder containing the {@code file} in a default system file >>> manager. >>> 933 * @param file the file >>> 934 * @return returns true if successfully opened >>> 935 * @throws NullPointerException if {@code file} is {@code null} >>> 936 * @throws IllegalArgumentException if the specified file doesn't >>> 937 * exist >>> 938 */ >>> 939 public boolean browseFileDirectory(File file) { >>> >>> So what happens if there is no "support" for this ? Exception or "false" ? >>> Are you comfortable that all these APIs that return "true" if successful >>> are >>> implementable on all platforms. i.e I mean that does the platform return >>> a value you can pass on as success/failure. >>> >>> --- >>> >>> 861 * Attaches a {@link FullScreenListener} to the specified top-level >>> 862 * {@link Window}. >>> 863 * >>> 864 * @param window to attach the {@link FullScreenListener} to >>> 865 * @param listener to be notified when a full screen event occurs >>> 866 * @throws IllegalArgumentException if window is not a >>> 867 * {@link javax.swing.RootPaneContainer} >>> 868 */ >>> 869 public void addWindowFullScreenListener(final Window window, >>> 870 final FullScreenListener >>> listener) { >>> >>> ------- >>> >>> Why does it have to be a RootPaneContainer ? Why is this tied to Swing ? >>> This appears to narrow it to JDialog and JWindow. >>> >>> -phil. >>> >> >