[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-awt-dev
Subject: Re: <AWT Dev> Review-request for 8143227: Platform-Specific Desktop Features
From: Yuri Nesterenko <yuri.nesterenko () oracle ! com>
Date: 2016-01-22 14:18:35
Message-ID: 56A23A3B.2080209 () oracle ! com
[Download RAW message or body]
Hi Alexander,
an unimportant note: before the spec is finalized,
could you please replace the StarOffice example with something
actual? StarOffice is discontinued long ago.
It is in Desktop.java.
Also, could you describe the minimal packaging procedures
for client applications, necessary to take the full advantage
of this new API just now? I understand it cannot be a part
of the specification but we'd need it to prepare the tests.
Thank you!
-yan
On 01/22/2016 10:16 AM, 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic