<AWT Dev> Review-request for 8143227: Platform-Specific Desktop Features
Alexander Zvegintsev
alexander.zvegintsev at oracle.com
Sun Jan 17 20:55:15 UTC 2016
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.
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160117/811b12f6/attachment-0001.html>
More information about the awt-dev
mailing list