<AWT Dev> Review-request for 8143227: Platform-Specific Desktop Features
Phil Race
philip.race at oracle.com
Fri Mar 4 19:07:54 UTC 2016
Approved.
-phil.
One comment on something you can't do anything about *yet*, is
that adding a new API package right in the same time frame jigsaw is
merging in to JDK9 creates a probable time window for a non-obvious
conflict.
See
http://cr.openjdk.java.net/~alanb/8142968/0/jdk/src/java.desktop/share/classes/module-info.java.html
where java.awt.desktop will need to be added to the list of exported
packages.
-phil.
On 03/03/2016 02:01 PM, Sergey Bylokhov wrote:
> In general the fix looks fine to me. All other cases can be covered
> via separate CRs.
>
> On 03.03.16 18:31, Alexander Zvegintsev wrote:
>> Hi,
>>
>> CCC is now in final state.
>>
>> For these raised questions I filed following issues:
>> https://bugs.openjdk.java.net/browse/JDK-8151184 [macosx] window does
>> not receive normal window events indicating the window is hidden
>> https://bugs.openjdk.java.net/browse/JDK-8151189 Possible
>> getAppContext() NPE in java.awt.Desktop and java.awt.Taskbar
>>
>> --
>> Thanks,
>> Alexander.
>>
>> On 02/24/2016 07:27 AM, Philip Race wrote:
>>> Hi,
>>>
>>> API-wise this now looks like it could go to CCC.
>>> I have not reviewed the implementation yet but that
>>> should not stop the CCC from being submitted as final.
>>>
>>> Perhaps the only concern I have is around AppHidden/Appreopened
>>> where I am not convinced that it is the right thing to not send normal
>>> window events indicating the window is hidden. What would the harm
>>> be in sending such events so that apps that aren't able to use these
>>> Mac-specific events because they pre-date these APIs don't get a
>>> notification which seems to mean the same thing to me.
>>> That could be an implementation detail or something we can
>>> refine later in an targeted CCC if needed.
>>>
>>> The AppContext issue is an implementation issue and we can discuss
>>> it later but the reason other places do not check is it never used to
>>> return null. Now it can. So do we really want to add more places
>>> that we need to fix ? In other words I don't think the fix is going
>>> to be to revert to it not returning null, so you are going to have
>>> to deal with it directly here.
>>>
>>> -phil.
>>>
>>> On 2/21/16, 5:08 PM, Alexander Zvegintsev wrote:
>>>> Hi Phil,
>>>> please see updated the webrev here
>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8143227/08/
>>>> and comments inline
>>>>
>>>> On 18.02.2016 0:10, Phil Race wrote:
>>>>> Desktop.java looks fine now. Moving on to the other API classes
>>>>>
>>>>> Top-level question :
>>>>> Why are AppEvent and TaskBar in java.awt and not java.awt.desktop ?
>>>> Agreed on AppEvent, but Taskbar is placed in java.awt on purpose to
>>>> make it adjacent with Desktop and SystemTray.
>>>>> And AppEvent seems to use a lot of nested classes.
>>>>> If they were in java.awt.desktop then they could be top-level classes
>>>>> without creating too much clutter. I don't think it matters that
>>>>> 'this
>>>>> is how the com.apple APIs were done' - people need to recode anyway
>>>>>
>>>>>
>>>>> AppEvent.java :
>>>>> more wildcards ..
>>>>> 28 import java.awt.desktop.*;
>>>>>
>>>>> I notice the docs in this file (and perhaps more I have yet to see)
>>>>> reference types without @code :-
>>>>> eg :
>>>>> * Constructs a FilesEvent
>>>>> * Constructs an OpenFilesEvent
>>>>> ..
>>>>> * Get the URI the app was asked to open
>>>>> 146 * @return the URI
>>>>>
>>>>> and more. Not essential I suppose but preferable.
>>>>>
>>>>> 69 public List<File> getFiles() {
>>>>> 70 return files;
>>>>> 71 }
>>>>>
>>>>> Is there any need to return a copy for any of these ?
>>>>>
>>>>> 95 * Gets the search term. The platform may
>>>>> additionally provide the search
>>>>> 96 * term that was used to find the files. This is for
>>>>> example the case
>>>>> 97 * on Mac OS X, when the files were opened using the
>>>>> Spotlight search
>>>>> 98 * menu or a Finder search window.
>>>>> 99 *
>>>>> 100 * This is useful for highlighting the search term
>>>>> in the documents when
>>>>> 101 * they are opened.
>>>>> 102 * @return the search term used to find the files
>>>>>
>>>>> Could we say "optionally" instead of "additionally"
>>>>> and make clear that it may be "null"
>>>>>
>>>>> a very long line :-
>>>>>
>>>>> 209 * Event sent when the application has become the
>>>>> foreground app, and when it has resigned being the foreground app.
>>>>>
>>>>> And "resigned" is a voluntary term. If something else is placed into
>>>>> the foreground the
>>>>> this app may not get asked if it wants to allow that.
>>>>> Maybe instead say "and when it is no longer the foreground app."
>>>>>
>>>> Done.
>>>>> Also is there anything we can (or should) say about how some of
>>>>> these events interact ?
>>>>>
>>>>> eg, if a foreground app is hidden does only the appHidden listener
>>>>> get called ?
>>>>>
>>>> Both listeners could be called, it's already mentioned here:
>>>>> * Called when the hidden app is shown again (but not
>>>>> necessarily brought to
>>>>> * the foreground).
>>>>> *
>>>>> * @param e event
>>>>> */
>>>>> public void appUnhidden(final AppHiddenEvent e);
>>>>
>>>>> BTW the term 'unhidden' makes sense if the app was previously
>>>>> 'hidden' but less so
>>>>> if the app is being newly shown.
>>>>>
>>>>>
>>>>> /**
>>>>> 252 * The system does not provide a reason for a
>>>>> session change.
>>>>> 253 */
>>>>> 254 @Native
>>>>> 255 public static final int REASON_UNSPECIFIED = 0x0;
>>>>> 256
>>>>>
>>>>> I think we should use an enum here.
>>>>>
>>>>>
>>>>> Also unless there is a reason I have not yet come across, as many as
>>>>> possible
>>>>> of these classes should be marked 'final'
>>>>>
>>>>>
>>>>> Taskbar.java :
>>>>>
>>>>> One meta-concern I have here is that it seems to have a very blurry
>>>>> distinction
>>>>> with existing API :
>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/SystemTray.html
>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/TrayIcon.html
>>>>>
>>>>> Aren't both of these APIs dealing with the same area ?
>>>>>
>>>>> Should we really add this new class or tweak system tray as needed ?
>>>> On Windows they dealing in the same area with taskbar, but on Mac OS
>>>> SystemTray and Taskbar(Dock) are separated. So I prefer to left it as
>>>> it is.
>>>>>
>>>>> /**
>>>>> 112 * Stops displaying the progress.
>>>>> 113 */
>>>>> 114 @Native
>>>>> 115 public static final int STATE_OFF = 0x0;
>>>>>
>>>>> Another case where an enum could be used.
>>>>>
>>>>>
>>>>> sun.awt.AppContext context = sun.awt.AppContext.getAppContext();
>>>>>
>>>>> these days this sometimes can return null ..
>>>>>
>>>> There are many usages of getAppContext() without null check all over
>>>> our code, so I think that this should be fixed under a separate bug.
>>>>> AppForegroundEvent :
>>>>> * @param e the app became foreground notification.
>>>>>
>>>>> I am not entirely sure what that means or even what it
>>>>> should say, perhaps because AppForegroundEvent does not
>>>>> have any fields.
>>>>> How about
>>>>> "@param e an event indicating that the receiving application is
>>>>> now the foreground app"
>>>>>
>>>>> 30 /**
>>>>> 31 * Implementors are notified when the app is hidden or shown
>>>>> by the user.
>>>>> 32 * This notification is helpful for discontinuing a costly
>>>>> animation if it's not visible to the user.
>>>>> 33 */
>>>>> 34 public interface AppHiddenListener extends
>>>>> SystemEventListener {
>>>>> .. we already can get notification when a window is hidden.
>>>>> Can I assume that this event indicates *all* windows are hidden and
>>>>> each hidden window still gets its hidden event ? And that there is
>>>>> no guarantee of order of delivery ?
>>>>>
>>>> It is a Mac specific hide, Cmd+H, or right click in dock and select
>>>> hide. All windows are hidden,
>>>> but in this case windows may not receive such notifications and only
>>>> gets AppHiddenEvent.
>>>>>
>>>>> /**
>>>>> 31 * Implementors receive notification when the app has been
>>>>> asked to open again.
>>>>> 32 *
>>>>> 33 * This notification is useful for showing a new document
>>>>> when your app has no open windows.
>>>>> 34 */
>>>>> 35 public interface AppReopenedListener extends
>>>>> SystemEventListener {
>>>>>
>>>>> So .. this means something more than that the windows have been
>>>>> hiddent ?
>>>>> Does it mean that all windows have been disposed() but the app is
>>>>> still running ?
>>>>> Is this the case when the system menu bar can be used be the user
>>>>> to request
>>>>> a new window ? Can you please give an example.
>>>>>
>>>> It is another Mac specific feature, it does exactly how it described.
>>>> You can have no windows(not even created), no system menu bar and
>>>> some running thread, AppReopenedListener
>>>> will be called on click in dock icon or on double click on the
>>>> application executable.
>>>>
>>>>> -phil.
>>>>>
>>>>>
>>>>> On 02/16/2016 07:04 AM, Alexander Zvegintsev wrote:
>>>>>> Hi Phil,
>>>>>>
>>>>>> thanks for the review, please see updated webrev here:
>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8143227/07/
>>>>>> --
>>>>>> Thanks,
>>>>>> Alexander.
>>>>>> On 02/15/2016 09:58 PM, Phil Race wrote:
>>>>>>> Desktop.java : 28 import java.awt.desktop.*; Can we replace this
>>>>>>> wild card import with an enumeration of the imported classes. I am
>>>>>>> sure you need all of them but it is still recommended practice.
>>>>>>> Also I do not see where you are adding the new package to the ones
>>>>>>> for which javadoc is generated. This would be an edit to
>>>>>>> $TOPLEVEL/common/CORE_PKGS.gmk I am focusing first on the API part
>>>>>>> of this so you can finalize the CCC.
>>>>>>> > 43 * The {@code Desktop} class allows interact with various
>>>>>>> desktop capabilities.
>>>>>>> interact -> interaction
>>>>>>>
>>>>>>> Or better
>>>>>>> The {@code Desktop} class allows interaction with various platform
>>>>>>> desktop capabilities.
>>>>>>>
>>>>>>> > * @since 1.9 These should all be @since 9 < 130 * Returns the
>>>>>>> {@code Desktop}
>>>>>>> instance of the current > 268 * Returns the <code>Desktop</code>
>>>>>>> instance of the current
>>>>>>>
>>>>>>> I am surprised to see this changed .. we are making the opposite
>>>>>>> update elsewhere.
>>>>>>> All the cases you have changed need to be changed back.
>>>>>>>
>>>>>>> >641 * Adds sub-types of {@link SystemEventListener} to listen for
>>>>>>> notifications Does that link work ? The referenced class is in a
>>>>>>> different package. I am fairly sure that in all such cases you
>>>>>>> need to fully qualify the class using the package. I believe that
>>>>>>> javac should run doclint as part of the JDK build so you should
>>>>>>> examine the output/logs.
>>>>>>>
>>>>>>> 686 * @param aboutHandler the handler to respond to the
>>>>>>> 687 * @throws UnsupportedOperationException if the current
>>>>>>> platform seems like line 686 is incomplete. Same for line 704 :
>>>>>>> 704 * @param preferencesHandler the handler to respond to the
>>>>>>>
>>>>>>> 801
>>>>>>> 802 /**
>>>>>>> 803 * Sets the default strategy used to quit this application. The
>>>>>>> default is
>>>>>>> 804 * calling SYSTEM_EXIT_0.
>>>>>>> 805 *
>>>>>>> 806 * @param strategy the way this application should be shutdown
>>>>>>> 807 * @throws UnsupportedOperationException if the current platform
>>>>>>> 808 * does not support the {@link
>>>>>>> Desktop.Action#APP_QUIT_STRATEGY} action
>>>>>>> 809 * @see QuitStrategy
>>>>>>> 810 * @since 1.9
>>>>>>> 811 */
>>>>>>> 812 public void setQuitStrategy(final QuitStrategy strategy) {
>>>>>>> 813 checkActionSupport(Action.APP_QUIT_STRATEGY);
>>>>>>> 814 peer.setQuitStrategy(strategy);
>>>>>>>
>>>>>>>
>>>>>>> Some of the actions discuss permissions and others do not.
>>>>>>>
>>>>>>>
>>>>>>> Shouldn't this say something about permissions ? You do need
>>>>>>> permission to
>>>>>>> exit the VM, so should you be able to set a QuitStrategy if you
>>>>>>> don't have
>>>>>>> such permission ??
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> More later ..
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 01/21/2016 11:16 PM, Alexander Zvegintsev wrote:
>>>>>>>> Hi Semyon,
>>>>>>>>
>>>>>>>> I am not sure about flexibility, but providing additional info
>>>>>>>> for a user session change could be useful
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8143227/05/
>>>>>>>> (changed awt_Toolkit.cpp, AppEvent.java,
>>>>>>>> UserSessionListener.java, _AppEventHandler.java)
>>>>>>>> --
>>>>>>>> Thanks,
>>>>>>>> Alexander.
>>>>>>>> On 01/19/2016 11:52 AM, Semyon Sadetsky wrote:
>>>>>>>>> Hi Alexander,
>>>>>>>>>
>>>>>>>>> What do you think about accompanying the application events with
>>>>>>>>> a flag containing the extended information that may be provided
>>>>>>>>> by various native platforms? For example, the session events may
>>>>>>>>> provide a reason on the Windows platform.
>>>>>>>>> Also this may add flexibility that allows to support new
>>>>>>>>> features in the future.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>> On 1/17/2016 11:55 PM, Alexander Zvegintsev wrote:
>>>>>>>>>> Hi Semyon,
>>>>>>>>>>> Is it possible to use WM_QUERYENDSESSION for
>>>>>>>>>>> Action.APP_SUDDEN_TERMINATION?
>>>>>>>>>> Sure, so please see updated webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8143227/04/
>>>>>>>>>>
>>>>>>>>>> awt_Toolkit.cpp:
>>>>>>>>>> extended list of supported messages for user session listener.
>>>>>>>>>>
>>>>>>>>>> awt_Desktop.cpp, awt_Toolkit.cpp, WDesktopPeer.java:
>>>>>>>>>> added SuddenTerminaton support for Windows
>>>>>>>>>> --
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexander.
>>>>>>>>>> On 01/15/2016 04:14 PM, Semyon Sadetsky wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 1/15/2016 12:39 PM, Alexander Zvegintsev wrote:
>>>>>>>>>>>> Hi Semyon,
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, it is just LOCK/UNLOCK for now, because it is the most
>>>>>>>>>>>> common scenario of desktop usage.
>>>>>>>>>>>>
>>>>>>>>>>>> Do you mean that we should consider remote desktop logins
>>>>>>>>>>>> too? Something like:
>>>>>>>>>>>>
>>>>>>>>>>>> if (wParam == WTS_CONSOLE_CONNECT
>>>>>>>>>>>> || wParam == WTS_CONSOLE_DISCONNECT
>>>>>>>>>>>> || wParam == WTS_REMOTE_CONNECT
>>>>>>>>>>>> || wParam == WTS_REMOTE_DISCONNECT
>>>>>>>>>>>> || wParam == WTS_SESSION_UNLOCK
>>>>>>>>>>>> || wParam == WTS_SESSION_LOCK) {
>>>>>>>>>>>>
>>>>>>>>>>>> BOOL activate = wParam == WTS_CONSOLE_CONNECT
>>>>>>>>>>>> || wParam ==
>>>>>>>>>>>> WTS_REMOTE_CONNECT
>>>>>>>>>>>> || wParam ==
>>>>>>>>>>>> WTS_SESSION_UNLOCK;
>>>>>>>>>>>> env->CallStaticVoidMethod(clzz, AwtToolkit::userSessionMID,
>>>>>>>>>>>> activate
>>>>>>>>>>>> ? JNI_TRUE
>>>>>>>>>>>> : JNI_FALSE);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>> That's seems better to me.
>>>>>>>>>>>> Or if you refer to WTS_SESSION_LOGOFF, then it seems useless
>>>>>>>>>>>> for us,
>>>>>>>>>>>> AFAIK only services will receive this notification, and
>>>>>>>>>>>> anyway all apps the user was running are already killed by
>>>>>>>>>>>> this time.
>>>>>>>>>>> Is it possible to use WM_QUERYENDSESSION for
>>>>>>>>>>> Action.APP_SUDDEN_TERMINATION?
>>>>>>>>>>>
>>>>>>>>>>> --Semyon
>>>>>>>>>>>> --
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexander.
>>>>>>>>>>>> On 12.01.2016 19:21, Semyon Sadetsky wrote:
>>>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>>>
>>>>>>>>>>>>> awt_Toolkit.cpp:
>>>>>>>>>>>>>
>>>>>>>>>>>>> case WM_WTSSESSION_CHANGE: {
>>>>>>>>>>>>> jclass clzz =
>>>>>>>>>>>>> env->FindClass("sun/awt/windows/WDesktopPeer");
>>>>>>>>>>>>> DASSERT(clzz != NULL);
>>>>>>>>>>>>> if (!clzz) throw std::bad_alloc();
>>>>>>>>>>>>>
>>>>>>>>>>>>> if (wParam == WTS_SESSION_LOCK || wParam ==
>>>>>>>>>>>>> WTS_SESSION_UNLOCK) {
>>>>>>>>>>>>> env->CallStaticVoidMethod(clzz, AwtToolkit::userSessionMID,
>>>>>>>>>>>>> wParam == WTS_SESSION_UNLOCK
>>>>>>>>>>>>> ? JNI_TRUE
>>>>>>>>>>>>> : JNI_FALSE);
>>>>>>>>>>>>> }
>>>>>>>>>>>>> break;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> So only the WTS_SESSION_UNLOCK is propagated to java as a
>>>>>>>>>>>>> session act/deact and other messages just ignored?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Other messages:
>>>>>>>>>>>>> #define WTS_CONSOLE_CONNECT 0x1
>>>>>>>>>>>>> #define WTS_CONSOLE_DISCONNECT 0x2
>>>>>>>>>>>>> #define WTS_REMOTE_CONNECT 0x3
>>>>>>>>>>>>> #define WTS_REMOTE_DISCONNECT 0x4
>>>>>>>>>>>>> #define WTS_SESSION_LOGON 0x5
>>>>>>>>>>>>> #define WTS_SESSION_LOGOFF 0x6
>>>>>>>>>>>>> #define WTS_SESSION_LOCK 0x7
>>>>>>>>>>>>> #define WTS_SESSION_REMOTE_CONTROL
>>>>>>>>>>>>>
>>>>>>>>>>>>> some of them seems to me more suitable to be chosen as the
>>>>>>>>>>>>> session act/deact event. Could you comment that for me?
>>>>>>>>>>>>>
>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/24/2015 6:02 PM, Alexander Zvegintsev 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
>
More information about the awt-dev
mailing list