Re: Review-request for 8143227: Platform-Specific Desktop Features

Alexander, I'm still worried about the way to call windows taskbar's COM objects using the ShelFolder invoker. The ShellFolder invoker is serialized (it may send one request at a time and other operations are blocked it returns). Requests to folder interfaces may take tens of seconds for

Re: Review-request for 8143227: Platform-Specific Desktop Features

> On Mar 5, 2016, at 1:48 AM, Alexander Zvegintsev > wrote: > > Fixed: http://cr.openjdk.java.net/~azvegint/jdk/9/8143227/09/ modules.xml change looks fine. Thanks for the update. Mandy > > -- > Thanks, > Alexander. > > On 03/05/2016 04:10 AM, Mandy Chung

Re: Review-request for 8143227: Platform-Specific Desktop Features

Fixed: http://cr.openjdk.java.net/~azvegint/jdk/9/8143227/09/ -- Thanks, Alexander. On 03/05/2016 04:10 AM, Mandy Chung wrote: On Mar 4, 2016, at 11:07 AM, Phil Race wrote: Approved. -phil. One comment on something you can't do anything about *yet*, is that adding a

Re: Review-request for 8143227: Platform-Specific Desktop Features

> On Mar 4, 2016, at 11:07 AM, Phil Race wrote: > > 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

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

I think that this fine is at is. Regarding permissions I filed the JDK-8151190 issue: https://bugs.openjdk.java.net/browse/JDK-8151190 Revise permissions for java.awt.Desktop and java.awt.Taskbar -- Thanks, Alexander. On 02/24/2016 08:12 PM, Sergey Bylokhov wrote: Small question about

Re: Review-request for 8143227: Platform-Specific Desktop Features

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()

Re: Review-request for 8143227: Platform-Specific Desktop Features

Small question about moveToTrash(). Should we describe that the user can delete folders as well? Also I am not sure about permissions which we check. For example the usual File.delete() calls "SM.checkDelete()" but we check SM.checkWrite() for "<>". Moreover checkFileValidation() checks the

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

NB: if you create an application with taskbar menu and a progress bar and register it with Unity, then start 2 instances of the application and then call getTaskbar().setIconBadge(null) in the first instance (not in the second), result will be, completely removed taskbar menu. Perhaps it is a

Re: Review-request for 8143227: Platform-Specific Desktop Features

Hi Alexander, Thank you for the update. It works for me. One additional remark. You do not call ::CoUninitialize() in awt_Taskbar.cpp. And I'm not sure that COM init/uninit can be done from arbitrary thread without aftereffects. MSDN states the next: A thread must call CoUninitialize once

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

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,

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

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) {

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

Hi Alexander! On 11/20/2015 07:34 PM, Alexander Zvegintsev wrote: Hello Yuri, Thanks for you testing! If I start the application from dash, I have progress reported and the menu on the right click. I _don't have_, however, application menu ("File" etc.). By etc. menu did you mean a global

Re: Review-request for 8143227: Platform-Specific Desktop Features

Hi Alexander, On 11/19/2015 06:23 PM, Alexander Zvegintsev wrote: Hi Yuri, Nice catch! Just tested on Ubuntu 14.04.3, it does not have libunity.so symlink to libuity.so.9. so we should try to load version 9 instead of 0 in awt_Taskbar.c: -#define UNITY_LIB_VERSIONED

Re: Review-request for 8143227: Platform-Specific Desktop Features

Hello Yuri, Thanks for you testing! If I start the application from dash, I have progress reported and the menu on the right click. I _don't have_, however, application menu ("File" etc.). By etc. menu did you mean a global menu[0] (which may be implemented by Desktop.setMenuBar() later)

Re: Review-request for 8143227: Platform-Specific Desktop Features

Hi Anthony, many thanks for your input! You are right, most of FileManager API looks like an alien in java.awt.desktop, so let it be revised as separate CR. This CR will cover only Desktop and Taskbar classes. http://cr.openjdk.java.net/~azvegint/jdk/9/8143227/01/ FileManager removed,

Re: Review-request for 8143227: Platform-Specific Desktop Features

Do we have the similar functionality already in the Desktop.open() if the folder is passed to it? Or this method do some additional things? it also selects the specified file, doc updated in .02 -- Thanks, Alexander. On 11/20/2015 08:12 PM, Sergey Bylokhov wrote: On 20.11.15 8:32, Alexander

Re: Review-request for 8143227: Platform-Specific Desktop Features

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

Re: Review-request for 8143227: Platform-Specific Desktop Features

Hi Yuri, Nice catch! Just tested on Ubuntu 14.04.3, it does not have libunity.so symlink to libuity.so.9. so we should try to load version 9 instead of 0 in awt_Taskbar.c: -#define UNITY_LIB_VERSIONED VERSIONED_JNI_LIB_NAME("unity", "0") +#define UNITY_LIB_VERSIONED

Re: Review-request for 8143227: Platform-Specific Desktop Features

Hi Alexander, I tried it with Ubuntu 14.04.3, and it started indeed from dash or a command line as a gray rectangle. Once I added isSupported() for every Action and separately for the Taskbar, it reported, just like jdk9b91, that only OPEN was supported and nothing else. Is it OK? dconf editor

Re: Review-request for 8143227: Platform-Specific Desktop Features

FYI. I start to check the osx part. On 18.11.15 17:01, Alexander Zvegintsev wrote: Hi Alexander, resending the same webrev under the new ID https://bugs.openjdk.java.net/browse/JDK-8143227 http://cr.openjdk.java.net/~azvegint/jdk/9/8143227/00/ The approach is pretty the same as it was in