<AWT Dev> Review-request for 8143227: Platform-Specific Desktop Features

[Alexander Zvegintsev]

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.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20151124/252a602d/attachment-0001.html>