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);
          }

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.

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





Reply via email to