From javalists at cbfiddle.com Tue Apr 3 02:35:40 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 2 Apr 2018 19:35:40 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors Message-ID: Please review the following change to the macOS AWT. Bug: https://bugs.openjdk.java.net/browse/JDK-8194327 Webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.00/ The goal of this change is to allow a Java desktop application on macOS to properly coexist with a native utility panel, such as the native color chooser. The native color chooser is an example of a window that can become the key (focused) window but cannot become the main window. If the previously active window is a Java frame, it should resign key window status (lose focus), but retain the main window status. A window that is main but not key does not own the keyboard focus, but it appears active, and if it is using the screen menu bar, it may be invoked to process a menu item action (if the menu item is not already handled by the key window). The current macOS AWT does not support this combination of window states. A Java window is either key and main, or neither. When the color chooser becomes key (obtains focus), the Java frame resigns both key and main status. This change allows the key window status to be resigned while retaining the main window status, with the appropriate behavior. Note that with this change, it remains impossible to implement a Java window that behaves like the native color chooser (i.e., can become key but not main). That would require a much bigger change. Alan From magnus.ihse.bursie at oracle.com Tue Apr 3 12:37:12 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 3 Apr 2018 14:37:12 +0200 Subject: [11] Review Request: 8200146 Remove the appletviewer launcher In-Reply-To: <419d6585-fa7f-f14a-bac8-3129ceb53c8b@oracle.com> References: <419d6585-fa7f-f14a-bac8-3129ceb53c8b@oracle.com> Message-ID: On 2018-03-31 00:52, Sergey Bylokhov wrote: > Hello. > Please review fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200146 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8200146/webrev.00 Build changes look good. /Magnus > CSR: https://bugs.openjdk.java.net/browse/JDK-8200549 > > Fix description: > ?- The appletviewer launcher was removed from jdk/bin > ?- The man pages were removed > ?- Two tests which used appletviewer launcher directly were removed > > Note that the appletviewer was deprecated in in jdk9: > https://bugs.openjdk.java.net/browse/JDK-8074165 > From hs at tagtraum.com Tue Apr 3 13:48:09 2018 From: hs at tagtraum.com (Hendrik Schreiber) Date: Tue, 3 Apr 2018 15:48:09 +0200 Subject: [11] JDK-8181910: [macos] Support dark title bars on macOS In-Reply-To: <9e2fcb3c-425e-6ad7-7778-5a297902df64@oracle.com> References: <9e2fcb3c-425e-6ad7-7778-5a297902df64@oracle.com> Message-ID: Hey, I was wondering how this is going. Are you guys still stuck, waiting for Denis to help out? -hendrik > On Mar 30, 2018, at 07:32, shashidhara.veerabhadraiah at oracle.com wrote: > > Sure. I did had a confusion to put for review though but did not know what to do and felt not to keep waiting. Thanks for the direction Sergey. > > Thanks and regards, > Shashi > > > On 29/03/18 7:45 PM, Sergey Bylokhov wrote: >> Unfortunately we cannot accept the patch which were suggested in the description of the bug. Initially it was implemented in JetBrains JRE. We can accept it if someone from the JetBrains will contribute it. >> >> Maybe Denis who is author of the fix can help? >> >> On 28/03/2018 02:29, Shashidhara Veerabhadraiah wrote: >>> Hi All, Please review an enhancement for the below bug: >>> >>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8181910 >>> >>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8181910/webrev.00/ >>> >>> This utilizes the NSAppearance to set the appearance theme to dark or light. >>> >>> Thanks and regards, >>> >>> Shashi >>> >> >> > From Sergey.Bylokhov at oracle.com Tue Apr 3 19:50:05 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 3 Apr 2018 12:50:05 -0700 Subject: [11] JDK-8181910: [macos] Support dark title bars on macOS In-Reply-To: References: <9e2fcb3c-425e-6ad7-7778-5a297902df64@oracle.com> Message-ID: Yes, this fix can be contributed by someone from the JB. On 03/04/2018 06:48, Hendrik Schreiber wrote: > Hey, > > I was wondering how this is going. Are you guys still stuck, waiting for Denis to help out? > > -hendrik > > >> On Mar 30, 2018, at 07:32, shashidhara.veerabhadraiah at oracle.com wrote: >> >> Sure. I did had a confusion to put for review though but did not know what to do and felt not to keep waiting. Thanks for the direction Sergey. >> >> Thanks and regards, >> Shashi >> >> >> On 29/03/18 7:45 PM, Sergey Bylokhov wrote: >>> Unfortunately we cannot accept the patch which were suggested in the description of the bug. Initially it was implemented in JetBrains JRE. We can accept it if someone from the JetBrains will contribute it. >>> >>> Maybe Denis who is author of the fix can help? >>> >>> On 28/03/2018 02:29, Shashidhara Veerabhadraiah wrote: >>>> Hi All, Please review an enhancement for the below bug: >>>> >>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8181910 >>>> >>>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8181910/webrev.00/ >>>> >>>> This utilizes the NSAppearance to set the appearance theme to dark or light. >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>> >>> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Apr 4 06:43:36 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 3 Apr 2018 23:43:36 -0700 Subject: [11] Review Request: 8187392 Deprecated methods in the peers can be removed Message-ID: Hello. Please review fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8187392 Webrev can be found at: http://cr.openjdk.java.net/~serb/8187392/webrev.05 In jdk1.0 era the "java.awt.peer.ComponentPeer" interface had a few methods which were replaced and removed in jdk1.1, but some of implementations of these methods were not removed(just deprecated). This change will remove them. -- Best regards, Sergey. From krishna.addepalli at oracle.com Wed Apr 4 08:09:36 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Wed, 4 Apr 2018 01:09:36 -0700 (PDT) Subject: [11] Review Request: 8187392 Deprecated methods in the peers can be removed In-Reply-To: References: Message-ID: <7dac0231-cf7d-4792-b09b-fe0f822c6948@default> Hi Sergey, The changes look fine to me. Thanks, Krishna -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, April 4, 2018 12:14 PM To: awt-dev at openjdk.java.net Subject: [11] Review Request: 8187392 Deprecated methods in the peers can be removed Hello. Please review fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8187392 Webrev can be found at: http://cr.openjdk.java.net/~serb/8187392/webrev.05 In jdk1.0 era the "java.awt.peer.ComponentPeer" interface had a few methods which were replaced and removed in jdk1.1, but some of implementations of these methods were not removed(just deprecated). This change will remove them. -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Wed Apr 4 15:49:40 2018 From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com) Date: Wed, 4 Apr 2018 21:19:40 +0530 Subject: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. In-Reply-To: <636d9ff1-b9ef-4a9e-9a65-b0892e9bfa6b@default> References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default> <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default> <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com> <992a8202-6ac9-4c16-9fe5-c316e314bed5@default> <814c85c6-0d8d-468c-a2af-fefa79e59ef7@default> <66fcf064-b200-4d6d-ac06-b78517074f00@default> <9fd92bf5-113c-782c-92e9-7b061ace2a6c@oracle.com> <27586cbb-be2c-4941-ade4-8493b501542b@default> <410e40d6-e7d7-4b2d-8647-2dbeb8b82c18@default> <4f0dbe63-e640-8183-b136-08da1af3c5cf@oracle.com> <948a2586-88e3-47cf-bf0f-84995eac96da@default> <80c936e4-fd72-437b-970a-4a71117e24f9@default> <636d9ff1-b9ef-4a9e-9a65-b0892e9bfa6b@default> Message-ID: <6ebb8b51-5d59-a5e5-2b05-551c4637c210@oracle.com> Hi, Gentle reminder to review this fix for the enhancement JDK-8148344. Thanks and regards, Shashi On 26/03/18 11:23 AM, Shashidhara Veerabhadraiah wrote: > Hi, Please review the updated Webrev containing the requested changes: > > http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.05/ > > I believe this change implements a new feature of Unicode key input and the corresponding key event generation without affecting the existing ascii key input and key event generations. Hence the regression should be less with this change. > > Some notes with respect to implementation: > 1. On linux platform, native api's present only for the extended ascii support and hence no idea of Unicode input in this platform. > 2. On mac platform, I have used the below native api's to implement the Unicode input to a component and key event trigger from the component to the respective key listener. > https://developer.apple.com/documentation/coregraphics/1456120-cgeventkeyboardgetunicodestring > https://developer.apple.com/documentation/coregraphics/1456028-cgeventkeyboardsetunicodestring?language=objc > (Set and get Unicode key is supported via the core graphics event(CGEvent) which is part of the NSEvent structure which is the base structure for event implementation on mac) > 3. On windows platform, I have used the below native api's to perform this job: > https://msdn.microsoft.com/en-us/library/windows/desktop/ms646310(v=vs.85).aspx > (SendInput api supports the Unicode input via the flag KEYEVENTF_UNICODE) > https://msdn.microsoft.com/en-us/library/windows/desktop/ms646271(v=vs.85).aspx > (Upon VK_PACKET, Get and decode the message via GetMessage() and TranslateMessage(). This produces a WM_CHAR message containing the respective Unicode key) > > Thanks and regards, > Shashi > > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, November 27, 2017 11:43 PM > To: Shashidhara Veerabhadraiah ; Semyon Sadetsky ; awt-dev at openjdk.java.net > Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. > > Hi, Shashi. >>> Also we should check what events are come to the application when >>> this new API will be used. For example if 'm' will be pressed what >>> notifications will be posted to the >>> application?(keyTyped/keyPressed/keyReleased) > The test is still manual, I suggest to change it to automated and validate the behavior of "keyTyped/keyPressed/keyReleased". I suggest to implement it first and check that it works as expected on macOS and windows. After that we can take a look to the linux platform(For example I think KeyEvent.getExtendedKeyCodeForChar() should work on linux, and we can check can it be used in the proposed fix or not) > > On 20/11/2017 21:03, Shashidhara Veerabhadraiah wrote: >> Hi Sergey, Please find the code updates that you asked for. As discussed I have raised an exception for the linux platform as there is no equivalent functions being implemented yet. >> >> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.04/ >> >> shashi >> >> -----Original Message----- >> From: Shashidhara Veerabhadraiah >> Sent: Thursday, November 16, 2017 12:36 PM >> To: Sergey Bylokhov ; Semyon Sadetsky >> ; awt-dev at openjdk.java.net >> Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. >> >> Hi Sergey, Below are my replies: >> >> shashi >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Tuesday, November 14, 2017 3:32 AM >> To: Shashidhara Veerabhadraiah >> ; Semyon Sadetsky >> ; awt-dev at openjdk.java.net >> Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. >> >> Hi, Shashi. >> 115 @Override >> 116 public void keyReleaseUnicode( int key ) { >> 117 // No special functions that implements a unicode key press >> 118 // and release in linux platform. Hence falls back to the >> 119 // default ASCII key press/release functions. >> 120 keyReleaseImpl(key); >> 121 } >> >> We should do something in this part of the fix, because we cannot use unicode point as a keyCode. It will produce incorrect result. >> [Shashi] As discussed in the meeting, will add a unsupported exception in the following Webrev. >> >> Also we should check what events are come to the application when this >> new API will be used. For example if 'm' will be pressed what >> notifications will be posted to the >> application?(keyTyped/keyPressed/keyReleased) >> [Shashi] It sends out the keyPressed/keyReleased events(WM_KEYUP/WM_KEYDOWN) events. The current code takes into account of the Unicode chars and uses the Unicode functions like ::ToUnicodeEx() to scan the characters. >> >> On 05/11/2017 21:04, Shashidhara Veerabhadraiah wrote: >>> Hi Sergey, Please find the updated Webrev addressing your comments/requirements. >>> >>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.03/ >>> >>> Thanks and regards, >>> Shashi >>> >>> -----Original Message----- >>> From: Shashidhara Veerabhadraiah >>> Sent: Friday, October 27, 2017 6:44 PM >>> To: Sergey Bylokhov ; Semyon Sadetsky >>> ; awt-dev at openjdk.java.net >>> Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. >>> >>> Hi Sergey, below are my replies: >>> >>> Thanks and regards, >>> shashi >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Friday, October 27, 2017 11:47 AM >>> To: Shashidhara Veerabhadraiah >>> ; Semyon Sadetsky >>> ; awt-dev at openjdk.java.net >>> Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. >>> >>> Hi, Shashi. >>> - Do we need to check passed unicode code-point in Robot.java using checkKeycodeArgument(key);? >>> [Shashi] I think yes. If the key value is zero I believe we don't need to process further. >>> - Can you please clarify how it will work on linux where we will use code-point as a keycode? >>> [Shashi] There is no update being done to the linux source code as I could not find native call which can interpret the Unicode. Hence it will behave same as the original keypress() and keyrelease(). >>> - It would be good if the names of the parameters will be unified/corrected, for example: >>> private native void keyEventUnicode(int javaKeyCode, boolean keydown); "javaKeyCode" - Is it a java key code or a Unicode code-point? >>> [Shashi] Sure will update in the coming pass. >>> >>> Why the test is manual? Isn't an application should recognize this new functionality automatically? Additionally it would be good to test all key related listeners(keyTyped/keyPressed/keyReleased). >>> [Shashi] We need to be sure that the Unicode key indeed displayed as the standard Unicode. There is no other way to confirm that it is indeed been the same standard Unicode that's been displayed. >>> >>> Debug code in awt_Robot.cpp >>> if(isUnicode) {printf("In unicode func:%d", jkey); [Shashi] Sure will update in the coming pass. >>> >>> >>> Also I would like to propose an idea for discussion: probably it would be better to create only one Robot#type(codePoint) method? What do you think? >>> [Shashi] It can be done but the only problem is that it is kinda different from the keypress() and keyRelease() functions. If that's fine then it can be done. Please confirm based on that I will produce a new Webrev based on that. >>> >>> On 26/10/2017 21:39, Shashidhara Veerabhadraiah wrote: >>>> Hi Sergey\Semyon, Please do the review for the below bug. >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>>> *From:* Shashidhara Veerabhadraiah >>>> *Sent:* Thursday, September 21, 2017 2:14 PM >>>> *To:* Sergey Bylokhov ; Semyon Sadetsky >>>> ; awt-dev at openjdk.java.net >>>> *Subject:* Re: [10] JDK-8148344: Java robot keypress >>>> should be able to use extended key code characters as ? ? ?. >>>> >>>> Hi All, Please find the updated webrev containing a new test that is >>>> added to test out the software changes that were made under this >>>> enhancement. >>>> >>>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.02/ >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>>> *From:* Shashidhara Veerabhadraiah >>>> *Sent:* Thursday, September 21, 2017 11:37 AM >>>> *To:* Sergey Bylokhov >>> >; Semyon Sadetsky >>>> >; >>>> awt-dev at openjdk.java.net >>>> *Subject:* Re: [10] JDK-8148344: Java robot keypress >>>> should be able to use extended key code characters as ? ? ?. >>>> >>>> Hi Sergey, I was able to input the surrogate pairs and got the >>>> required output as shown below: >>>> >>>> Below is the output after we input the surrogate pairs: >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>>> -----Original Message----- >>>> From: Sergey Bylokhov >>>> Sent: Thursday, September 14, 2017 11:33 PM >>>> To: Shashidhara Veerabhadraiah >>>> >>> >; Semyon Sadetsky >>>> >; >>>> awt-dev at openjdk.java.net >>>> Subject: Re: [10] JDK-8148344: Java robot keypress should >>>> be able to use extended key code characters as ? ? ?. >>>> >>>> The java uses UTF16, I guess this new api should use it also, and we >>>> should check that the surrogate pairs will be supported. >>>> >>>> On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote: >>>> >>>> > Hi Sergey, Yes it represents the Unicode code point. The >>>> encoding is same as the window characteristic which is UTF 8 as implemented in Java. >>>> >>>> > >>>> >>>> > Thanks and regards, >>>> >>>> > Shashi >>>> >>>> > >>>> >>>> > -----Original Message----- >>>> >>>> > From: Sergey Bylokhov >>>> >>>> > Sent: Wednesday, September 13, 2017 5:22 AM >>>> >>>> > To: Shashidhara Veerabhadraiah >>>> >>>> > >>> >; Semyon Sadetsky >>>> >>>> > >>> >; >>>> awt-dev at openjdk.java.net >>>> >>>> > Subject: Re: [10] JDK-8148344: Java robot keypress >>>> should be able to use extended key code characters as ? ? ?. >>>> >>>> > >>>> >>>> > Hi, Shashi. >>>> >>>> > One initial question: >>>> >>>> > What is an int parameter of these methods means, is it a >>>> "Unicode code point"? What encoding utf8/utf16 should be used? >>>> >>>> > >>>> >>>> > On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote: >>>> >>>> >> Hi, I have updated the Webrev to accommodate the comments and >>>> here is >>>> >>>> >> the new Webrev: >>>> >>>> >> >>>> >>>> >> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/ >>>> >>>> >> >>>> >>>> >> I have separated the /_Unicode_/ keys input via java robot as >>>> a new >>>> >>>> >> set of /_public_/ api?s (this is in similar fashion as how the >>>> >>>> >> platform offers the Unicode keys input into the system) and >>>> this has >>>> >>>> >> been tested on all the platforms using the test file similar >>>> to the >>>> >>>> >> attached file in the bug. A more proper test file would be put >>>> for >>>> >>>> >> review in the subsequent reviews. >>>> >>>> >> >>>> >>>> >> Thanks and regards, >>>> >>>> >> >>>> >>>> >> Shashi >>>> >>>> >> >>>> >>>> >> *From:* Sergey Bylokhov >>>> >>>> >> *Sent:* Wednesday, August 30, 2017 2:33 AM >>>> >>>> >> *To:* Shashidhara Veerabhadraiah >>>> >>>> >> >>> > >>>> >>>> >> *Cc:* awt-dev at openjdk.java.net >>>> >>>> >>>> >> *Subject:* Re: [10] JDK-8148344: Java robot keypress >>>> should >>>> >>>> >> be able to use extended key code characters as ? ? ?. >>>> >>>> >> >>>> >>>> >> Hi, Shashi. >>>> >>>> >> >>>> >>>> >> This is part of this fix, to figure out how it will work for >>>> external >>>> >>>> >> applications. As you said this functionally can be useful for >>>> an >>>> >>>> >> onscreen keyboards, which virtually can have any possible >>>> keys, but >>>> >>>> >> we should check how the applications will react on such keys: >>>> >>>> >>?? ?- Will the application get some kind of keyPress/Release? >>>> >>>> >>?? ?- Will the application get some keyCode for such event? >>>> >>>> >>?? ?- Is it possible to get autorepeat for such keys?(between >>>> >>>> >> press/release) >>>> >>>> >> >>>> >>>> >> Depending from the answers above we can enhance existed robot >>>> API or >>>> >>>> >> provide a new one: >>>> >>>> >> like Robot.keyType(char)/etc >>>> >>>> >> >>>> >>>> >> ----- shashidhara.veerabhadraiah at oracle.com >>>> >>>> >>>> >> wrote: >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >> Hi Sergey, I was only able to add short cut keys in the >>>> Microsoft >>>> >>>> >> word but not as a system wide short cut key. There was no >>>> mechanism >>>> >>>> >> that I could find to add a short cut key for a Unicode char!! >>>> Can you >>>> >>>> >> please tell me the steps to do the same if you are aware of? >>>> >>>> >> >>>> >>>> >> Thanks and regards, >>>> >>>> >> >>>> >>>> >> shashi >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >> *From:*Sergey Bylokhov >>>> >>>> >>> *Sent:* Tuesday, August 22, 2017 8:34 PM >>>> >>>> >>> *To:* Shashidhara Veerabhadraiah >>>> >>>> >>> >>> >>>> >> > >>>> >>>> >>> *Cc:* awt-dev at openjdk.java.net >>>> >>>> >>>> >>> *Subject:* Re: [10] JDK-8148344: Java robot >>>> keypress >>>> >>>> >>> should be >>>> >>>> >> able to use extended key code characters as ? ? ?. >>>> >>>> >> >>>> >>>> >> Hi, Shashi. >>>> >>>> >>> Can you check how this Robot API will work when the >>>> application will have a shortcut for such key? Will such shortcuts >>>> will work after this fix? >>>> >>>> >>> >>>> >>>> >>> ----- shashidhara.veerabhadraiah at oracle.com >>>> >>>> >>>> >> wrote: >>>> >>>> >>>> >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >> Hi All, Please review fix for the /_enhancement_/ wherein the >>>> robot >>>> >>>> >> key press of non-ascii were interpreted as question marks. >>>> >>>> >> >>>> >>>> >> Issue: The robot key press events was handling only the ascii >>>> inputs >>>> >>>> >> and ignored the other Unicode inputs. Either it was throwing >>>> illegal >>>> >>>> >> argument exception in windows or does nothing on the mac for >>>> those >>>> >>>> >> Unicode inputs. >>>> >>>> >> >>>> >>>> >> Solution and fix: The platform specific api?s was unable >>>> handle the >>>> >>>> >> non-ascii inputs. I have modified the api?s to accept the >>>> non-ascii >>>> >>>> >> inputs and correspondingly send the message to the window to >>>> print >>>> >>>> >> the non-ascii characters as well. Below is the picture of how >>>> the >>>> >>>> >> non-ascii inputs are considered and printed onto the window. >>>> >>>> >> >>>> >>>> >> The solution spans across windows and mac platform and still >>>> in >>>> >>>> >> search of a solution for the Linux platform. The solution >>>> implements >>>> >>>> >> key scanning only upon existing valid ascii key was /_not_/ >>>> found and >>>> >>>> >> assumes it as Unicode key and sends the event to event queue >>>> to be >>>> >>>> >> processed as Unicode keys. Different formats are being used by >>>> >>>> >> different platform implementation of Unicode. For ex., per the >>>> below >>>> >>>> >> Unicode list, in the case of windows and mac, the key input >>>> can take >>>> >>>> >> decimal values whereas on Linux it can only take the Code values. >>>> >>>> >> >>>> >>>> >> On Linux, I was able to get the KeySym of Unicode keys but was >>>> unable >>>> >>>> >> to fake the key event as there was no mechanism available for >>>> the >>>> >>>> >> same(which sends the key event to window). Please let me know >>>> if >>>> >>>> >> there is any such mechanism available to simulate Unicode key >>>> events >>>> >>>> >> on Linux platform. Hence I think to raise a bug for the Linux >>>> >>>> >> platform and close this JDK-8148344 bug. >>>> >>>> >> >>>> >>>> >> Enhancement id: >>>> https://bugs.openjdk.java.net/browse/JDK-8148344 >>>> >>>> >> >>>> >>>> >> Webrev: >>>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/ >>>> >>>> >> >>>> >>>> >> Thanks and regards, >>>> >>>> >> >>>> >>>> >> Shashi >>>> >>>> >> >>>> >>>> > >>>> >>>> > >>>> >>>> > -- >>>> >>>> > Best regards, Sergey. >>>> >>>> > >>>> >>>> -- >>>> >>>> Best regards, Sergey. >>>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> -- >> Best regards, Sergey. >> > > -- > Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Wed Apr 4 15:51:49 2018 From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com) Date: Wed, 4 Apr 2018 21:21:49 +0530 Subject: [8u-backport] Review request for 8195738 : scroll poistion in ScrollPane is reset after calling validate() In-Reply-To: <6109d9f5-c51e-42f9-a7d0-93fceb011054@default> References: <10404fdb-0444-4d15-8d09-e7f499cbcb5a@default> <035c1dd3-f03a-46d5-88ed-fc7235a1ce76@default> <7f697864-ce44-4693-9a17-99f01fc659e6@default> <6109d9f5-c51e-42f9-a7d0-93fceb011054@default> Message-ID: <8bfddefe-b4e7-6ff8-e40b-3007c10f7c32@oracle.com> Hi Dipak, The changes looks fine to me. +1. Thanks and regards, Shashi On 30/03/18 11:24 AM, Dipak Kumar wrote: > > Requesting to review the changes mentioned in the trailing mail. > > It's a backport from Jdk-11 to Jdk-8. Backport is almost clean and > there is one line difference in the test file compare to Jdk-11. > > Awaiting response. > > Thanks, > > Dipak > > *From:*Dipak Kumar > *Sent:* 23 March 2018 12:43 > *To:* awt-dev at openjdk.java.net > *Subject:* RE: [8u-backport] Review request for 8195738 : > scroll poistion in ScrollPane is reset after calling validate() > > Just a gentle reminder. Requesting again to review the changes. > > Thanks, > > Dipak > > *From:*Shashidhara Veerabhadraiah > *Sent:* 20 March 2018 09:26 > *To:* Patrick Chen >; Dipak Kumar > > > *Cc:* awt-dev at openjdk.java.net > *Subject:* Re: [8u-backport] Review request for 8195738 : > scroll poistion in ScrollPane is reset after calling validate() > > Hi Patrick, For the case of scroll bar policy as SCROLLBARS_NEVER, we > used to call SetScrollInfo() with nMin and nMax as zero which used to > reset the already set value for the scroll bars. There is a better way > to resolve this by calling ShowScrollBar() and maintain the set size > of the scroll bar without resetting it. > > Since the code that does this job is present in cpp files which calls > the native api's, they need to be updated to accommodate this fix > which fixes the JBS bug. > > Hope this answers your question and do have a good day. > > Thanks and regards, > Shashi > > On 19/03/18 2:05 PM, Patrick Chen wrote: > > Hi, > > I am not to understand why ScrollPane.cpp was changed ? > > And why cpp files? > > Cheers > > 2018-03-19 6:25 GMT+01:00 Dipak Kumar >: > > Hi Patrick, > > File ?awt_ScrollPane.cpp? has already been reviewed as part of > JDK 11. The only difference between JDK 11 changeset and JDK 8 > backport is the test file (ScrollPaneValidateTest.java), not > awt_ScrollPane.cpp. > > I had mentioned that in my previous mail. > > If at all there is any concern related awt_ScrollPane.cpp file > then I think that should be dealt after filing another issue. > > Moreover I didn't really get your question. Out of two nested > if blocks, one has been removed and yes, variables are being > used and their declarations are still intact. > > Please let me know if you need any more info. > > Thanks, > > Dipak > > *From:* Patrick Chen [mailto:chen.j.patrick at gmail.com > ] > *Sent:* 14 March 2018 18:21 > *To:* Dipak Kumar > > *Cc:* awt-dev at openjdk.java.net > *Subject:* Re: [8u-backport] Review request for > 8195738 : scroll poistion in ScrollPane is reset after calling > validate() > > Hi, > > Why in src/windows/native/sun/windows/awt_ScrollPane.cpp did > you delete? the main condition? > > Means : the two variables are used isn't it ? > > Cheers, > > Pc > > 2018-03-14 11:02 GMT+01:00 Dipak Kumar >: > > Hi All, > > Please review the below patch (for 8u-backport) - > > Webrev : > http://cr.openjdk.java.net/~dkumar/8195738/webrev.00/ > > > JBS : https://bugs.openjdk.java.net/browse/JDK-8195738 > > JDK 11 changeset - > http://hg.openjdk.java.net/jdk/client/rev/96bebffe0be1 > > Patch pushed for JDK 11 applies cleanly to JDK 8 after > adjusting file path except 'headful' keyword has been > removed from the test as this is not defined for 8. > > Related Jtreg tests have been run against the proposed > patch and results are fine. > > Thanks, > > Dipak > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Apr 4 16:34:55 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 4 Apr 2018 09:34:55 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors In-Reply-To: References: Message-ID: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> Hi, Alan. A few comments about the test: - It is a mac specific and JtregNativeJdk should compile it on mac only - It should close all windows at the end, currently it leaves Finder opened. - it tries to use NSWindowStyleMask/NSWindowStyleMaskTitled which are available in >10.12. We only plan to move to 10.9 soon. So the test should skip it or use NSInteger/NSTitledWindowMask for macOS < MAC_OS_X_VERSION_10_12. - It looks like other tests in JtregNativeJdk.gmk use libtest+Some useful name, I suggest to use the same instead of bugid(same for the test name "Test.java"). BUILD_JDK_JTREG_LIBRARIES_LIBS_libtest819432 On 02/04/2018 19:35, Alan Snyder wrote: > Please review the following change to the macOS AWT. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8194327 > Webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.00/ > > The goal of this change is to allow a Java desktop application on macOS to properly coexist with a native utility panel, such as the native color chooser. > > The native color chooser is an example of a window that can become the key (focused) window but cannot become the main window. > If the previously active window is a Java frame, it should resign key window status (lose focus), but retain the main window status. > A window that is main but not key does not own the keyboard focus, but it appears active, and if it is using the screen menu bar, > it may be invoked to process a menu item action (if the menu item is not already handled by the key window). > > The current macOS AWT does not support this combination of window states. A Java window is either key and main, or neither. > When the color chooser becomes key (obtains focus), the Java frame resigns both key and main status. > > This change allows the key window status to be resigned while retaining the main window status, with the appropriate behavior. > > Note that with this change, it remains impossible to implement a Java window that behaves like the native color chooser (i.e., can become key but not main). > That would require a much bigger change. > > Alan > -- Best regards, Sergey. From dipak.kumar at oracle.com Thu Apr 5 08:27:27 2018 From: dipak.kumar at oracle.com (Dipak Kumar) Date: Thu, 5 Apr 2018 01:27:27 -0700 (PDT) Subject: [8u-backport] Review request for 8152974 : AWT hang occurrs when sequenced events arrive out of sequence Message-ID: <33882e86-c931-4a55-a3fb-47aace657599@default> Hi, Please review the below patch (for JDK 8u-dev backport) - Webrev : http://cr.openjdk.java.net/~dkumar/8152974/8u-dev_Backport/webrev.00/ JBS : https://bugs.openjdk.java.net/browse/JDK-8152974 JDK 11 changeset - http://hg.openjdk.java.net/jdk/client/rev/719064f540f3 Patch pushed for JDK 11 doesn't apply cleanly to JDK 8, mainly because of the line differences and key 'headful' has been removed from the test file. Related Jtreg tests have been run against the proposed patch and results are fine. Thanks, Dipak -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Thu Apr 5 08:48:32 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 5 Apr 2018 01:48:32 -0700 (PDT) Subject: [8u-backport] Review request for 8152974 : AWT hang occurrs when sequenced events arrive out of sequence In-Reply-To: <33882e86-c931-4a55-a3fb-47aace657599@default> References: <33882e86-c931-4a55-a3fb-47aace657599@default> Message-ID: <75c302b7-1008-4261-91a4-caed66181824@default> Looks fine to me. Thanks, Krishna From: Dipak Kumar Sent: Thursday, April 5, 2018 1:57 PM To: Sergey Bylokhov ; Semyon Sadetsky ; Philip Race ; Krishna Addepalli ; awt-dev at openjdk.java.net Subject: [8u-backport] Review request for 8152974 : AWT hang occurrs when sequenced events arrive out of sequence Hi, Please review the below patch (for JDK 8u-dev backport) - Webrev : http://cr.openjdk.java.net/~dkumar/8152974/8u-dev_Backport/webrev.00/ JBS : https://bugs.openjdk.java.net/browse/JDK-8152974 JDK 11 changeset - http://hg.openjdk.java.net/jdk/client/rev/719064f540f3 Patch pushed for JDK 11 doesn't apply cleanly to JDK 8, mainly because of the line differences and key 'headful' has been removed from the test file. Related Jtreg tests have been run against the proposed patch and results are fine. Thanks, Dipak -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Thu Apr 5 22:39:17 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 5 Apr 2018 23:39:17 +0100 Subject: [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 Message-ID: Hello, Could you please review the fix for jdk11? bug: https://bugs.openjdk.java.net/browse/JDK-8199627 webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/ Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1] Java already supports "Per-Monitor v1" mode. This change extends High DPI support in Java: in addition to element [2], a new element [3] is added to Java launcher manifest. The element is recognized by Windows 10 v1607 and above, PerMonitorV2 value is supported by Windows 10 v1703 and above. The most notable change for Java applications is that window title bar is scaled correctly when application window moves from one monitor to another or the scaling changes. When building, manifest tool generates warning for unknown element in manifest. It is because an older Windows SDK is used to build JDK which does not know about an element that was added later. The build succeeds despite the warning. Thank you in advance. Regards, Alexey [1] https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware [3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness From Sergey.Bylokhov at oracle.com Thu Apr 5 22:56:51 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 5 Apr 2018 15:56:51 -0700 Subject: [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 In-Reply-To: References: Message-ID: <5ede620b-7833-5124-c9ed-7cc61a7e3774@oracle.com> Looks fine. On 05/04/2018 15:39, Alexey Ivanov wrote: > Hello, > > Could you please review the fix for jdk11? > > bug: https://bugs.openjdk.java.net/browse/JDK-8199627 > webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/ > > > Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1] > > Java already supports "Per-Monitor v1" mode. This change extends High > DPI support in Java: in addition to element [2], a new > element [3] is added to Java launcher manifest. The > element is recognized by Windows 10 v1607 and above, > PerMonitorV2 value is supported by Windows 10 v1703 and above. > > The most notable change for Java applications is that window title bar > is scaled correctly when application window moves from one monitor to > another or the scaling changes. > > > When building, manifest tool generates warning for unknown > element in manifest. It is because an older Windows SDK > is used to build JDK which does not know about an element that was added > later. The build succeeds despite the warning. > > > Thank you in advance. > > Regards, > Alexey > > [1] > https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ > > > [2] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware > > > [3] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness > > -- Best regards, Sergey. From javalists at cbfiddle.com Thu Apr 5 23:15:42 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 5 Apr 2018 16:15:42 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors In-Reply-To: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> References: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> Message-ID: <22D883A4-B362-411D-82F7-76A418487ADE@cbfiddle.com> Thank you for your comments. Here is the updated webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.01/ Alan > On Apr 4, 2018, at 9:34 AM, Sergey Bylokhov wrote: > > Hi, Alan. > A few comments about the test: > - It is a mac specific and JtregNativeJdk should compile it on mac only > - It should close all windows at the end, currently it leaves Finder opened. > - it tries to use NSWindowStyleMask/NSWindowStyleMaskTitled which are available in >10.12. We only plan to move to 10.9 soon. So the test should skip it or use NSInteger/NSTitledWindowMask for macOS < MAC_OS_X_VERSION_10_12. > - It looks like other tests in JtregNativeJdk.gmk use libtest+Some useful name, I suggest to use the same instead of bugid(same for the test name "Test.java"). > BUILD_JDK_JTREG_LIBRARIES_LIBS_libtest819432 > > On 02/04/2018 19:35, Alan Snyder wrote: >> Please review the following change to the macOS AWT. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8194327 >> Webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.00/ >> The goal of this change is to allow a Java desktop application on macOS to properly coexist with a native utility panel, such as the native color chooser. >> The native color chooser is an example of a window that can become the key (focused) window but cannot become the main window. >> If the previously active window is a Java frame, it should resign key window status (lose focus), but retain the main window status. >> A window that is main but not key does not own the keyboard focus, but it appears active, and if it is using the screen menu bar, >> it may be invoked to process a menu item action (if the menu item is not already handled by the key window). >> The current macOS AWT does not support this combination of window states. A Java window is either key and main, or neither. >> When the color chooser becomes key (obtains focus), the Java frame resigns both key and main status. >> This change allows the key window status to be resigned while retaining the main window status, with the appropriate behavior. >> Note that with this change, it remains impossible to implement a Java window that behaves like the native color chooser (i.e., can become key but not main). >> That would require a much bigger change. >> Alan > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Sat Apr 7 00:25:46 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 6 Apr 2018 17:25:46 -0700 Subject: [11] Review Request: 8199932 Missing copyright header in AWT source code Message-ID: <668b7c74-bdd9-b26a-1427-6d833f032be9@oracle.com> Hello. Please review small cleanup for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8199932 Webrev can be found at: http://cr.openjdk.java.net/~serb/8199932/webrev.00 A few places were updated to have correct specification(gpl+cp). -- Best regards, Sergey. From manajit.halder at oracle.com Mon Apr 9 06:02:22 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Mon, 9 Apr 2018 11:32:22 +0530 Subject: [11] Review Request: 8199932 Missing copyright header in AWT source code In-Reply-To: <668b7c74-bdd9-b26a-1427-6d833f032be9@oracle.com> References: <668b7c74-bdd9-b26a-1427-6d833f032be9@oracle.com> Message-ID: Looks good to me. Regards, Manajit > On 07-Apr-2018, at 5:55 AM, Sergey Bylokhov wrote: > > Hello. > Please review small cleanup for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199932 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8199932/webrev.00 > > A few places were updated to have correct specification(gpl+cp). > > -- > Best regards, Sergey. From takiguc at linux.vnet.ibm.com Mon Apr 9 09:09:25 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 09 Apr 2018 18:09:25 +0900 Subject: Proposal:AIX's IME support Message-ID: <2ed52f9dc4e9487c7b3131b5af3666d9@linux.vnet.ibm.com> Hello, IBM would like to propose another Input Method Framework (IMF) implementation against IBM AIX platform. Same IMF implementation was used by IBM Java8 for AIX. IBM would like to contribute this IMF implementation to OpenJDK project. AIX's Input Method Editor (IME) working behavior is not same as Linux's and Solaris' one. On OpenJDK JDK9 for AIX, users cannot input any East Asian character with their locale by this IME. We think this situation is critical. Put modified files under src/java.desktop/aix/* directories in order not to affect the other unix platform. I'd like contribute following 4 files: M make/lib/Awt2dLibraries.gmk A src/java.desktop/aix/classes/sun/awt/X11InputMethod.java A src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c A src/java.desktop/aix/native/libawt_xawt/xawt/XlibWrapper.c We need to apply too many changes including JNI, so we copied following 3 files from unix directory to aix directory: * src/java.desktop/unix/classes/sun/awt/X11InputMethod.java * src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c * src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c Then, we modified them. I'd appreciate any feedback please, and how I would go about obtaining a sponsor and contributor? Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From sgehwolf at redhat.com Mon Apr 9 13:39:52 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 09 Apr 2018 15:39:52 +0200 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols Message-ID: <1523281192.148486.9.camel@redhat.com> Hi, Could somebody please review this build fix for libfontmanager.so. The issue for us is that with some LDFLAGS the build breaks as described in bug JDK-8196218. However, we cannot link to a providing library at build-time since we don't know which one it should be: libawt_headless or libawt_xawt. That has to happen at runtime. The proposed fix filters out relevant linker flags when libfontmanager is being built. More details are in the bug. Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/ Testing: I've run this through submit[1] and got the following results. SwingSet2 works fine for me on F27. I'm currently running some more tests on RHEL 7. --------------------- Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE. 0 Failed Tests Mach5 Tasks Results Summary NA: 0 UNABLE_TO_RUN: 0 EXECUTED_WITH_FAILURE: 0 KILLED: 0 PASSED: 82 FAILED: 1 Test 1 Failed tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64- debug-31 SetupFailedException in setup...profile run-test-prebuilt' , return value: 10 -------------------- Not sure what this test failure means. Could somebody at Oracle shed some light on this? Thanks, Severin From erik.joelsson at oracle.com Mon Apr 9 16:20:28 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 9 Apr 2018 09:20:28 -0700 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <1523281192.148486.9.camel@redhat.com> References: <1523281192.148486.9.camel@redhat.com> Message-ID: Hello Severin, I'm ok with this solution for now. Could you please reduce the indentation on line 652. In the build system we like 4 spaces for continuation indent [1] /Erik [1] http://openjdk.java.net/groups/build/doc/code-conventions.html On 2018-04-09 06:39, Severin Gehwolf wrote: > Hi, > > Could somebody please review this build fix for libfontmanager.so. The > issue for us is that with some LDFLAGS the build breaks as described in > bug JDK-8196218. However, we cannot link to a providing library at > build-time since we don't know which one it should be: libawt_headless > or libawt_xawt. That has to happen at runtime. The proposed fix filters > out relevant linker flags when libfontmanager is being built. More > details are in the bug. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/ > > Testing: I've run this through submit[1] and got the following results. > SwingSet2 works fine for me on F27. I'm currently running some more > tests on RHEL 7. > > --------------------- > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE. > > 0 Failed Tests > > Mach5 Tasks Results Summary > > NA: 0 > UNABLE_TO_RUN: 0 > EXECUTED_WITH_FAILURE: 0 > KILLED: 0 > PASSED: 82 > FAILED: 1 > Test > > 1 Failed > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64- > debug-31 SetupFailedException in setup...profile run-test-prebuilt' , > return value: 10 > -------------------- > > Not sure what this test failure means. Could somebody at Oracle shed > some light on this? > > Thanks, > Severin From Sergey.Bylokhov at oracle.com Mon Apr 9 22:39:29 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 9 Apr 2018 15:39:29 -0700 Subject: Proposal:AIX's IME support In-Reply-To: <2ed52f9dc4e9487c7b3131b5af3666d9@linux.vnet.ibm.com> References: <2ed52f9dc4e9487c7b3131b5af3666d9@linux.vnet.ibm.com> Message-ID: <428f37b3-0a64-b727-2426-9c96fd8155a9@oracle.com> Hi, Ichiroh. Your contribution is welcome. Can you send the change for review as a webrev on cr.openjdk.java.net? On 09/04/2018 02:09, Ichiroh Takiguchi wrote: > Hello, > IBM would like to propose another Input Method Framework (IMF) > implementation against IBM AIX platform. > Same IMF implementation was used by IBM Java8 for AIX. > IBM would like to contribute this IMF implementation to OpenJDK project. > > AIX's Input Method Editor (IME) working behavior is not same as Linux's > and Solaris' one. > On OpenJDK JDK9 for AIX, users cannot input any East Asian character > with their locale by this IME. > We think this situation is critical. > Put modified files under src/java.desktop/aix/* directories in order not > to affect the other unix platform. > > I'd like contribute following 4 files: > M make/lib/Awt2dLibraries.gmk > A src/java.desktop/aix/classes/sun/awt/X11InputMethod.java > A src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c > A src/java.desktop/aix/native/libawt_xawt/xawt/XlibWrapper.c > > We need to apply too many changes including JNI, so we copied following > 3 files from unix directory to aix directory: > * src/java.desktop/unix/classes/sun/awt/X11InputMethod.java > * src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > * src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c > Then, we modified them. > > I'd appreciate any feedback please, and how I would go about obtaining a > sponsor and contributor? > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Apr 9 23:06:05 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 9 Apr 2018 16:06:05 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors In-Reply-To: <22D883A4-B362-411D-82F7-76A418487ADE@cbfiddle.com> References: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> <22D883A4-B362-411D-82F7-76A418487ADE@cbfiddle.com> Message-ID: Hi, Alan. I just found a few side effects in the test. - All other tests(actually all java applications) which are executed after the new test will show colorPanel(until it will not be closed manually). - If the Finder will be opened in full screen(or in the location where the test will show the test windows) then the test will fail. Maybe it is better to use some other application to deactivate the test? Can we implement it using other java application?(you can run the same TestMainKeyWindow.main() and pass some flag to it) On 05/04/2018 16:15, Alan Snyder wrote: > Thank you for your comments. Here is the updated webrev: > > http://cr.openjdk.java.net/~serb/alans/8194327/webrev.01/ > > Alan > > >> On Apr 4, 2018, at 9:34 AM, Sergey Bylokhov >> > wrote: >> >> Hi, Alan. >> A few comments about the test: >> - It is a mac specific and JtregNativeJdk should compile it on mac only >> - It should close all windows at the end, currently it leaves Finder >> opened. >> - it tries to use NSWindowStyleMask/NSWindowStyleMaskTitled which are >> available in ?>10.12. We only plan to move to 10.9 soon. So the test >> should skip it or use NSInteger/NSTitledWindowMask for macOS < >> MAC_OS_X_VERSION_10_12. >> - It looks like other tests in JtregNativeJdk.gmk use libtest+Some >> useful name, I suggest to use the same instead of bugid(same for the >> test name "Test.java"). >> BUILD_JDK_JTREG_LIBRARIES_LIBS_libtest819432 >> >> On 02/04/2018 19:35, Alan Snyder wrote: >>> Please review the following change to the macOS AWT. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194327 >>> Webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.00/ >>> The goal of this change is to allow a Java desktop application on >>> macOS to properly coexist with a native utility panel, such as the >>> native color chooser. >>> The native color chooser is an example of a window that can become >>> the key (focused) window but cannot become the main window. >>> If the previously active window is a Java frame, it should resign key >>> window status (lose focus), but retain the main window status. >>> A window that is main but not key does not own the keyboard focus, >>> but it appears active, and if it is using the screen menu bar, >>> it may be invoked to process a menu item action (if the menu item is >>> not already handled by the key window). >>> The current macOS AWT does not support this combination of window >>> states. A Java window is either key and main, or neither. >>> When the color chooser becomes key (obtains focus), the Java frame >>> resigns both key and main status. >>> This change allows the key window status to be resigned while >>> retaining the main window status, with the appropriate behavior. >>> Note that with this change, it remains impossible to implement a Java >>> window that behaves like the native color chooser (i.e., can become >>> key but not main). >>> That would require a much bigger change. >>> ??Alan >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Apr 10 01:24:29 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 9 Apr 2018 18:24:29 -0700 Subject: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. In-Reply-To: <636d9ff1-b9ef-4a9e-9a65-b0892e9bfa6b@default> References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default> <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default> <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com> <992a8202-6ac9-4c16-9fe5-c316e314bed5@default> <814c85c6-0d8d-468c-a2af-fefa79e59ef7@default> <66fcf064-b200-4d6d-ac06-b78517074f00@default> <9fd92bf5-113c-782c-92e9-7b061ace2a6c@oracle.com> <27586cbb-be2c-4941-ade4-8493b501542b@default> <410e40d6-e7d7-4b2d-8647-2dbeb8b82c18@default> <4f0dbe63-e640-8183-b136-08da1af3c5cf@oracle.com> <948a2586-88e3-47cf-bf0f-84995eac96da@default> <80c936e4-fd72-437b-970a-4a71117e24f9@default> <636d9ff1-b9ef-4a9e-9a65-b0892e9bfa6b@default> Message-ID: Hi, Shashi. Did you check what kind of events are generated by the external input methods? Currently input methods works on all platforms and are able to generate some type events for the Unicode symbols which are absent on the keyboard(for example Chinese hieroglyphs) but we already can handle such events(maybe we generate only TYPE events in this case and skip keyPress/keyRelease events). On 25/03/2018 22:53, Shashidhara Veerabhadraiah wrote: > Hi, Please review the updated Webrev containing the requested changes: > > http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.05/ > > I believe this change implements a new feature of Unicode key input and the corresponding key event generation without affecting the existing ascii key input and key event generations. Hence the regression should be less with this change. > > Some notes with respect to implementation: > 1. On linux platform, native api's present only for the extended ascii support and hence no idea of Unicode input in this platform. > 2. On mac platform, I have used the below native api's to implement the Unicode input to a component and key event trigger from the component to the respective key listener. > https://developer.apple.com/documentation/coregraphics/1456120-cgeventkeyboardgetunicodestring > https://developer.apple.com/documentation/coregraphics/1456028-cgeventkeyboardsetunicodestring?language=objc > (Set and get Unicode key is supported via the core graphics event(CGEvent) which is part of the NSEvent structure which is the base structure for event implementation on mac) > 3. On windows platform, I have used the below native api's to perform this job: > https://msdn.microsoft.com/en-us/library/windows/desktop/ms646310(v=vs.85).aspx > (SendInput api supports the Unicode input via the flag KEYEVENTF_UNICODE) > https://msdn.microsoft.com/en-us/library/windows/desktop/ms646271(v=vs.85).aspx > (Upon VK_PACKET, Get and decode the message via GetMessage() and TranslateMessage(). This produces a WM_CHAR message containing the respective Unicode key) > > Thanks and regards, > Shashi > > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, November 27, 2017 11:43 PM > To: Shashidhara Veerabhadraiah ; Semyon Sadetsky ; awt-dev at openjdk.java.net > Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. > > Hi, Shashi. >>> Also we should check what events are come to the application when >>> this new API will be used. For example if 'm' will be pressed what >>> notifications will be posted to the >>> application?(keyTyped/keyPressed/keyReleased) > > The test is still manual, I suggest to change it to automated and validate the behavior of "keyTyped/keyPressed/keyReleased". I suggest to implement it first and check that it works as expected on macOS and windows. After that we can take a look to the linux platform(For example I think KeyEvent.getExtendedKeyCodeForChar() should work on linux, and we can check can it be used in the proposed fix or not) > > On 20/11/2017 21:03, Shashidhara Veerabhadraiah wrote: >> Hi Sergey, Please find the code updates that you asked for. As discussed I have raised an exception for the linux platform as there is no equivalent functions being implemented yet. >> >> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.04/ >> >> shashi >> >> -----Original Message----- >> From: Shashidhara Veerabhadraiah >> Sent: Thursday, November 16, 2017 12:36 PM >> To: Sergey Bylokhov ; Semyon Sadetsky >> ; awt-dev at openjdk.java.net >> Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. >> >> Hi Sergey, Below are my replies: >> >> shashi >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Tuesday, November 14, 2017 3:32 AM >> To: Shashidhara Veerabhadraiah >> ; Semyon Sadetsky >> ; awt-dev at openjdk.java.net >> Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. >> >> Hi, Shashi. >> 115 @Override >> 116 public void keyReleaseUnicode( int key ) { >> 117 // No special functions that implements a unicode key press >> 118 // and release in linux platform. Hence falls back to the >> 119 // default ASCII key press/release functions. >> 120 keyReleaseImpl(key); >> 121 } >> >> We should do something in this part of the fix, because we cannot use unicode point as a keyCode. It will produce incorrect result. >> [Shashi] As discussed in the meeting, will add a unsupported exception in the following Webrev. >> >> Also we should check what events are come to the application when this >> new API will be used. For example if 'm' will be pressed what >> notifications will be posted to the >> application?(keyTyped/keyPressed/keyReleased) >> [Shashi] It sends out the keyPressed/keyReleased events(WM_KEYUP/WM_KEYDOWN) events. The current code takes into account of the Unicode chars and uses the Unicode functions like ::ToUnicodeEx() to scan the characters. >> >> On 05/11/2017 21:04, Shashidhara Veerabhadraiah wrote: >>> Hi Sergey, Please find the updated Webrev addressing your comments/requirements. >>> >>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.03/ >>> >>> Thanks and regards, >>> Shashi >>> >>> -----Original Message----- >>> From: Shashidhara Veerabhadraiah >>> Sent: Friday, October 27, 2017 6:44 PM >>> To: Sergey Bylokhov ; Semyon Sadetsky >>> ; awt-dev at openjdk.java.net >>> Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. >>> >>> Hi Sergey, below are my replies: >>> >>> Thanks and regards, >>> shashi >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Friday, October 27, 2017 11:47 AM >>> To: Shashidhara Veerabhadraiah >>> ; Semyon Sadetsky >>> ; awt-dev at openjdk.java.net >>> Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. >>> >>> Hi, Shashi. >>> - Do we need to check passed unicode code-point in Robot.java using checkKeycodeArgument(key);? >>> [Shashi] I think yes. If the key value is zero I believe we don't need to process further. >>> - Can you please clarify how it will work on linux where we will use code-point as a keycode? >>> [Shashi] There is no update being done to the linux source code as I could not find native call which can interpret the Unicode. Hence it will behave same as the original keypress() and keyrelease(). >>> - It would be good if the names of the parameters will be unified/corrected, for example: >>> private native void keyEventUnicode(int javaKeyCode, boolean keydown); "javaKeyCode" - Is it a java key code or a Unicode code-point? >>> [Shashi] Sure will update in the coming pass. >>> >>> Why the test is manual? Isn't an application should recognize this new functionality automatically? Additionally it would be good to test all key related listeners(keyTyped/keyPressed/keyReleased). >>> [Shashi] We need to be sure that the Unicode key indeed displayed as the standard Unicode. There is no other way to confirm that it is indeed been the same standard Unicode that's been displayed. >>> >>> Debug code in awt_Robot.cpp >>> if(isUnicode) {printf("In unicode func:%d", jkey); [Shashi] Sure will update in the coming pass. >>> >>> >>> Also I would like to propose an idea for discussion: probably it would be better to create only one Robot#type(codePoint) method? What do you think? >>> [Shashi] It can be done but the only problem is that it is kinda different from the keypress() and keyRelease() functions. If that's fine then it can be done. Please confirm based on that I will produce a new Webrev based on that. >>> >>> On 26/10/2017 21:39, Shashidhara Veerabhadraiah wrote: >>>> Hi Sergey\Semyon, Please do the review for the below bug. >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>>> *From:* Shashidhara Veerabhadraiah >>>> *Sent:* Thursday, September 21, 2017 2:14 PM >>>> *To:* Sergey Bylokhov ; Semyon Sadetsky >>>> ; awt-dev at openjdk.java.net >>>> *Subject:* Re: [10] JDK-8148344: Java robot keypress >>>> should be able to use extended key code characters as ? ? ?. >>>> >>>> Hi All, Please find the updated webrev containing a new test that is >>>> added to test out the software changes that were made under this >>>> enhancement. >>>> >>>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.02/ >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>>> *From:* Shashidhara Veerabhadraiah >>>> *Sent:* Thursday, September 21, 2017 11:37 AM >>>> *To:* Sergey Bylokhov >>> >; Semyon Sadetsky >>>> >; >>>> awt-dev at openjdk.java.net >>>> *Subject:* Re: [10] JDK-8148344: Java robot keypress >>>> should be able to use extended key code characters as ? ? ?. >>>> >>>> Hi Sergey, I was able to input the surrogate pairs and got the >>>> required output as shown below: >>>> >>>> Below is the output after we input the surrogate pairs: >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>>> -----Original Message----- >>>> From: Sergey Bylokhov >>>> Sent: Thursday, September 14, 2017 11:33 PM >>>> To: Shashidhara Veerabhadraiah >>>> >>> >; Semyon Sadetsky >>>> >; >>>> awt-dev at openjdk.java.net >>>> Subject: Re: [10] JDK-8148344: Java robot keypress should >>>> be able to use extended key code characters as ? ? ?. >>>> >>>> The java uses UTF16, I guess this new api should use it also, and we >>>> should check that the surrogate pairs will be supported. >>>> >>>> On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote: >>>> >>>> > Hi Sergey, Yes it represents the Unicode code point. The >>>> encoding is same as the window characteristic which is UTF 8 as implemented in Java. >>>> >>>> > >>>> >>>> > Thanks and regards, >>>> >>>> > Shashi >>>> >>>> > >>>> >>>> > -----Original Message----- >>>> >>>> > From: Sergey Bylokhov >>>> >>>> > Sent: Wednesday, September 13, 2017 5:22 AM >>>> >>>> > To: Shashidhara Veerabhadraiah >>>> >>>> > >>> >; Semyon Sadetsky >>>> >>>> > >>> >; >>>> awt-dev at openjdk.java.net >>>> >>>> > Subject: Re: [10] JDK-8148344: Java robot keypress >>>> should be able to use extended key code characters as ? ? ?. >>>> >>>> > >>>> >>>> > Hi, Shashi. >>>> >>>> > One initial question: >>>> >>>> > What is an int parameter of these methods means, is it a >>>> "Unicode code point"? What encoding utf8/utf16 should be used? >>>> >>>> > >>>> >>>> > On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote: >>>> >>>> >> Hi, I have updated the Webrev to accommodate the comments and >>>> here is >>>> >>>> >> the new Webrev: >>>> >>>> >> >>>> >>>> >> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/ >>>> >>>> >> >>>> >>>> >> I have separated the /_Unicode_/ keys input via java robot as >>>> a new >>>> >>>> >> set of /_public_/ api?s (this is in similar fashion as how the >>>> >>>> >> platform offers the Unicode keys input into the system) and >>>> this has >>>> >>>> >> been tested on all the platforms using the test file similar >>>> to the >>>> >>>> >> attached file in the bug. A more proper test file would be put >>>> for >>>> >>>> >> review in the subsequent reviews. >>>> >>>> >> >>>> >>>> >> Thanks and regards, >>>> >>>> >> >>>> >>>> >> Shashi >>>> >>>> >> >>>> >>>> >> *From:* Sergey Bylokhov >>>> >>>> >> *Sent:* Wednesday, August 30, 2017 2:33 AM >>>> >>>> >> *To:* Shashidhara Veerabhadraiah >>>> >>>> >> >>> > >>>> >>>> >> *Cc:* awt-dev at openjdk.java.net >>>> >>>> >>>> >> *Subject:* Re: [10] JDK-8148344: Java robot keypress >>>> should >>>> >>>> >> be able to use extended key code characters as ? ? ?. >>>> >>>> >> >>>> >>>> >> Hi, Shashi. >>>> >>>> >> >>>> >>>> >> This is part of this fix, to figure out how it will work for >>>> external >>>> >>>> >> applications. As you said this functionally can be useful for >>>> an >>>> >>>> >> onscreen keyboards, which virtually can have any possible >>>> keys, but >>>> >>>> >> we should check how the applications will react on such keys: >>>> >>>> >>?? ?- Will the application get some kind of keyPress/Release? >>>> >>>> >>?? ?- Will the application get some keyCode for such event? >>>> >>>> >>?? ?- Is it possible to get autorepeat for such keys?(between >>>> >>>> >> press/release) >>>> >>>> >> >>>> >>>> >> Depending from the answers above we can enhance existed robot >>>> API or >>>> >>>> >> provide a new one: >>>> >>>> >> like Robot.keyType(char)/etc >>>> >>>> >> >>>> >>>> >> ----- shashidhara.veerabhadraiah at oracle.com >>>> >>>> >>>> >> wrote: >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >> Hi Sergey, I was only able to add short cut keys in the >>>> Microsoft >>>> >>>> >> word but not as a system wide short cut key. There was no >>>> mechanism >>>> >>>> >> that I could find to add a short cut key for a Unicode char!! >>>> Can you >>>> >>>> >> please tell me the steps to do the same if you are aware of? >>>> >>>> >> >>>> >>>> >> Thanks and regards, >>>> >>>> >> >>>> >>>> >> shashi >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >> *From:*Sergey Bylokhov >>>> >>>> >>> *Sent:* Tuesday, August 22, 2017 8:34 PM >>>> >>>> >>> *To:* Shashidhara Veerabhadraiah >>>> >>>> >>> >>> >>>> >> > >>>> >>>> >>> *Cc:* awt-dev at openjdk.java.net >>>> >>>> >>>> >>> *Subject:* Re: [10] JDK-8148344: Java robot >>>> keypress >>>> >>>> >>> should be >>>> >>>> >> able to use extended key code characters as ? ? ?. >>>> >>>> >> >>>> >>>> >> Hi, Shashi. >>>> >>>> >>> Can you check how this Robot API will work when the >>>> application will have a shortcut for such key? Will such shortcuts >>>> will work after this fix? >>>> >>>> >>> >>>> >>>> >>> ----- shashidhara.veerabhadraiah at oracle.com >>>> >>>> >>>> >> wrote: >>>> >>>> >>>> >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >> Hi All, Please review fix for the /_enhancement_/ wherein the >>>> robot >>>> >>>> >> key press of non-ascii were interpreted as question marks. >>>> >>>> >> >>>> >>>> >> Issue: The robot key press events was handling only the ascii >>>> inputs >>>> >>>> >> and ignored the other Unicode inputs. Either it was throwing >>>> illegal >>>> >>>> >> argument exception in windows or does nothing on the mac for >>>> those >>>> >>>> >> Unicode inputs. >>>> >>>> >> >>>> >>>> >> Solution and fix: The platform specific api?s was unable >>>> handle the >>>> >>>> >> non-ascii inputs. I have modified the api?s to accept the >>>> non-ascii >>>> >>>> >> inputs and correspondingly send the message to the window to >>>> print >>>> >>>> >> the non-ascii characters as well. Below is the picture of how >>>> the >>>> >>>> >> non-ascii inputs are considered and printed onto the window. >>>> >>>> >> >>>> >>>> >> The solution spans across windows and mac platform and still >>>> in >>>> >>>> >> search of a solution for the Linux platform. The solution >>>> implements >>>> >>>> >> key scanning only upon existing valid ascii key was /_not_/ >>>> found and >>>> >>>> >> assumes it as Unicode key and sends the event to event queue >>>> to be >>>> >>>> >> processed as Unicode keys. Different formats are being used by >>>> >>>> >> different platform implementation of Unicode. For ex., per the >>>> below >>>> >>>> >> Unicode list, in the case of windows and mac, the key input >>>> can take >>>> >>>> >> decimal values whereas on Linux it can only take the Code values. >>>> >>>> >> >>>> >>>> >> On Linux, I was able to get the KeySym of Unicode keys but was >>>> unable >>>> >>>> >> to fake the key event as there was no mechanism available for >>>> the >>>> >>>> >> same(which sends the key event to window). Please let me know >>>> if >>>> >>>> >> there is any such mechanism available to simulate Unicode key >>>> events >>>> >>>> >> on Linux platform. Hence I think to raise a bug for the Linux >>>> >>>> >> platform and close this JDK-8148344 bug. >>>> >>>> >> >>>> >>>> >> Enhancement id: >>>> https://bugs.openjdk.java.net/browse/JDK-8148344 >>>> >>>> >> >>>> >>>> >> Webrev: >>>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/ >>>> >>>> >> >>>> >>>> >> Thanks and regards, >>>> >>>> >> >>>> >>>> >> Shashi >>>> >>>> >> >>>> >>>> > >>>> >>>> > >>>> >>>> > -- >>>> >>>> > Best regards, Sergey. >>>> >>>> > >>>> >>>> -- >>>> >>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From sgehwolf at redhat.com Tue Apr 10 11:25:36 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 10 Apr 2018 13:25:36 +0200 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: References: <1523281192.148486.9.camel@redhat.com> Message-ID: <1523359536.4542.2.camel@redhat.com> Hi Erik, On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: > Hello Severin, > > I'm ok with this solution for now. Thanks for the review! > Could you please reduce the indentation on line 652. In the build system > we like 4 spaces for continuation indent [1] Done. New webrev at: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02 Could someone from awt-dev have a look at this too? Thanks! Cheers, Severin > /Erik > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.html > > On 2018-04-09 06:39, Severin Gehwolf wrote: > > Hi, > > > > Could somebody please review this build fix for libfontmanager.so. The > > issue for us is that with some LDFLAGS the build breaks as described in > > bug JDK-8196218. However, we cannot link to a providing library at > > build-time since we don't know which one it should be: libawt_headless > > or libawt_xawt. That has to happen at runtime. The proposed fix filters > > out relevant linker flags when libfontmanager is being built. More > > details are in the bug. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/ > > > > Testing: I've run this through submit[1] and got the following results. > > SwingSet2 works fine for me on F27. I'm currently running some more > > tests on RHEL 7. > > > > --------------------- > > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE. > > > > 0 Failed Tests > > > > Mach5 Tasks Results Summary > > > > NA: 0 > > UNABLE_TO_RUN: 0 > > EXECUTED_WITH_FAILURE: 0 > > KILLED: 0 > > PASSED: 82 > > FAILED: 1 > > Test > > > > 1 Failed > > > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64- > > debug-31 SetupFailedException in setup...profile run-test-prebuilt' , > > return value: 10 > > -------------------- > > > > Not sure what this test failure means. Could somebody at Oracle shed > > some light on this? > > > > Thanks, > > Severin > > From sgehwolf at redhat.com Tue Apr 10 11:30:56 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 10 Apr 2018 13:30:56 +0200 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <1523281192.148486.9.camel@redhat.com> References: <1523281192.148486.9.camel@redhat.com> Message-ID: <1523359856.4542.7.camel@redhat.com> On Mon, 2018-04-09 at 15:39 +0200, Severin Gehwolf wrote: > Hi, > > Could somebody please review this build fix for libfontmanager.so. The > issue for us is that with some LDFLAGS the build breaks as described in > bug JDK-8196218. However, we cannot link to a providing library at > build-time since we don't know which one it should be: libawt_headless > or libawt_xawt. That has to happen at runtime. The proposed fix filters > out relevant linker flags when libfontmanager is being built. More > details are in the bug. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 Latest webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02/ > Testing: I've run this through submit[1] and got the following results. > SwingSet2 works fine for me on F27. I'm currently running some more > tests on RHEL 7. I've finished testing on RHEL 7 by manually verifying that not both libawt_xawt and libawt_headless get loaded when running SwingSet. Could somebody tell me what this failure below is about? Thanks, Severin > --------------------- > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE. > > 0 Failed Tests > > Mach5 Tasks Results Summary > > NA: 0 > UNABLE_TO_RUN: 0 > EXECUTED_WITH_FAILURE: 0 > KILLED: 0 > PASSED: 82 > FAILED: 1 > Test > > 1 Failed > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64- > debug-31 SetupFailedException in setup...profile run-test-prebuilt' , > return value: 10 > -------------------- > > Not sure what this test failure means. Could somebody at Oracle shed > some light on this? > > Thanks, > Severin From takiguc at linux.vnet.ibm.com Tue Apr 10 12:16:51 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 10 Apr 2018 21:16:51 +0900 Subject: Proposal:AIX's IME support In-Reply-To: <428f37b3-0a64-b727-2426-9c96fd8155a9@oracle.com> References: <2ed52f9dc4e9487c7b3131b5af3666d9@linux.vnet.ibm.com> <428f37b3-0a64-b727-2426-9c96fd8155a9@oracle.com> Message-ID: Hello Sergey. I don't have permission to put webrev file into cr.openjdk.java.net. Would you be able to put it there if I email it to you ? On 2018-04-10 07:39, Sergey Bylokhov wrote: > Hi, Ichiroh. > Your contribution is welcome. Can you send the change for review as a > webrev on cr.openjdk.java.net? > > On 09/04/2018 02:09, Ichiroh Takiguchi wrote: >> Hello, >> IBM would like to propose another Input Method Framework (IMF) >> implementation against IBM AIX platform. >> Same IMF implementation was used by IBM Java8 for AIX. >> IBM would like to contribute this IMF implementation to OpenJDK >> project. >> >> AIX's Input Method Editor (IME) working behavior is not same as >> Linux's and Solaris' one. >> On OpenJDK JDK9 for AIX, users cannot input any East Asian character >> with their locale by this IME. >> We think this situation is critical. >> Put modified files under src/java.desktop/aix/* directories in order >> not to affect the other unix platform. >> >> I'd like contribute following 4 files: >> M make/lib/Awt2dLibraries.gmk >> A src/java.desktop/aix/classes/sun/awt/X11InputMethod.java >> A src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c >> A src/java.desktop/aix/native/libawt_xawt/xawt/XlibWrapper.c >> >> We need to apply too many changes including JNI, so we copied >> following 3 files from unix directory to aix directory: >> * src/java.desktop/unix/classes/sun/awt/X11InputMethod.java >> * src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >> * src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c >> Then, we modified them. >> >> I'd appreciate any feedback please, and how I would go about obtaining >> a sponsor and contributor? >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> From philip.race at oracle.com Tue Apr 10 15:36:42 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 10 Apr 2018 08:36:42 -0700 Subject: Proposal:AIX's IME support In-Reply-To: References: <2ed52f9dc4e9487c7b3131b5af3666d9@linux.vnet.ibm.com> <428f37b3-0a64-b727-2426-9c96fd8155a9@oracle.com> Message-ID: <7A128842-B6DC-4604-A6E0-AE3862225E13@oracle.com> There are committers at IBM who should be able to do this for you. -Phil. > On Apr 10, 2018, at 5:16 AM, Ichiroh Takiguchi wrote: > > Hello Sergey. > > I don't have permission to put webrev file into cr.openjdk.java.net. > Would you be able to put it there if I email it to you ? > >> On 2018-04-10 07:39, Sergey Bylokhov wrote: >> Hi, Ichiroh. >> Your contribution is welcome. Can you send the change for review as a >> webrev on cr.openjdk.java.net? >>> On 09/04/2018 02:09, Ichiroh Takiguchi wrote: >>> Hello, >>> IBM would like to propose another Input Method Framework (IMF) implementation against IBM AIX platform. >>> Same IMF implementation was used by IBM Java8 for AIX. >>> IBM would like to contribute this IMF implementation to OpenJDK project. >>> AIX's Input Method Editor (IME) working behavior is not same as Linux's and Solaris' one. >>> On OpenJDK JDK9 for AIX, users cannot input any East Asian character with their locale by this IME. >>> We think this situation is critical. >>> Put modified files under src/java.desktop/aix/* directories in order not to affect the other unix platform. >>> I'd like contribute following 4 files: >>> M make/lib/Awt2dLibraries.gmk >>> A src/java.desktop/aix/classes/sun/awt/X11InputMethod.java >>> A src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c >>> A src/java.desktop/aix/native/libawt_xawt/xawt/XlibWrapper.c >>> We need to apply too many changes including JNI, so we copied following 3 files from unix directory to aix directory: >>> * src/java.desktop/unix/classes/sun/awt/X11InputMethod.java >>> * src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>> * src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c >>> Then, we modified them. >>> I'd appreciate any feedback please, and how I would go about obtaining a sponsor and contributor? >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. > From erik.joelsson at oracle.com Tue Apr 10 16:34:10 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 10 Apr 2018 09:34:10 -0700 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <1523359536.4542.2.camel@redhat.com> References: <1523281192.148486.9.camel@redhat.com> <1523359536.4542.2.camel@redhat.com> Message-ID: Looks good. Thanks! /Erik On 2018-04-10 04:25, Severin Gehwolf wrote: > Hi Erik, > > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: >> Hello Severin, >> >> I'm ok with this solution for now. > Thanks for the review! > >> Could you please reduce the indentation on line 652. In the build system >> we like 4 spaces for continuation indent [1] > Done. New webrev at: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02 > > Could someone from awt-dev have a look at this too? Thanks! > > Cheers, > Severin > >> /Erik >> >> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >> >> On 2018-04-09 06:39, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review this build fix for libfontmanager.so. The >>> issue for us is that with some LDFLAGS the build breaks as described in >>> bug JDK-8196218. However, we cannot link to a providing library at >>> build-time since we don't know which one it should be: libawt_headless >>> or libawt_xawt. That has to happen at runtime. The proposed fix filters >>> out relevant linker flags when libfontmanager is being built. More >>> details are in the bug. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/ >>> >>> Testing: I've run this through submit[1] and got the following results. >>> SwingSet2 works fine for me on F27. I'm currently running some more >>> tests on RHEL 7. >>> >>> --------------------- >>> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE. >>> >>> 0 Failed Tests >>> >>> Mach5 Tasks Results Summary >>> >>> NA: 0 >>> UNABLE_TO_RUN: 0 >>> EXECUTED_WITH_FAILURE: 0 >>> KILLED: 0 >>> PASSED: 82 >>> FAILED: 1 >>> Test >>> >>> 1 Failed >>> >>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64- >>> debug-31 SetupFailedException in setup...profile run-test-prebuilt' , >>> return value: 10 >>> -------------------- >>> >>> Not sure what this test failure means. Could somebody at Oracle shed >>> some light on this? >>> >>> Thanks, >>> Severin >> From erik.joelsson at oracle.com Tue Apr 10 16:36:41 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 10 Apr 2018 09:36:41 -0700 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <1523359856.4542.7.camel@redhat.com> References: <1523281192.148486.9.camel@redhat.com> <1523359856.4542.7.camel@redhat.com> Message-ID: <6ed2dd10-0363-3f26-310e-c8783ab35042@oracle.com> On 2018-04-10 04:30, Severin Gehwolf wrote: > On Mon, 2018-04-09 at 15:39 +0200, Severin Gehwolf wrote: >> Hi, >> >> Could somebody please review this build fix for libfontmanager.so. The >> issue for us is that with some LDFLAGS the build breaks as described in >> bug JDK-8196218. However, we cannot link to a providing library at >> build-time since we don't know which one it should be: libawt_headless >> or libawt_xawt. That has to happen at runtime. The proposed fix filters >> out relevant linker flags when libfontmanager is being built. More >> details are in the bug. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 > Latest webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02/ > >> Testing: I've run this through submit[1] and got the following results. >> SwingSet2 works fine for me on F27. I'm currently running some more >> tests on RHEL 7. > I've finished testing on RHEL 7 by manually verifying that not both > libawt_xawt and libawt_headless get loaded when running SwingSet. > > Could somebody tell me what this failure below is about? This was an internal infrastructure failure. I would say it's safe to ignore. /Erik > Thanks, > Severin > >> --------------------- >> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE. >> >> 0 Failed Tests >> >> Mach5 Tasks Results Summary >> >> NA: 0 >> UNABLE_TO_RUN: 0 >> EXECUTED_WITH_FAILURE: 0 >> KILLED: 0 >> PASSED: 82 >> FAILED: 1 >> Test >> >> 1 Failed >> >> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64- >> debug-31 SetupFailedException in setup...profile run-test-prebuilt' , >> return value: 10 >> -------------------- >> >> Not sure what this test failure means. Could somebody at Oracle shed >> some light on this? >> >> Thanks, >> Severin From javalists at cbfiddle.com Tue Apr 10 18:39:01 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 10 Apr 2018 11:39:01 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors In-Reply-To: References: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> <22D883A4-B362-411D-82F7-76A418487ADE@cbfiddle.com> Message-ID: <35F57A44-F3B1-484B-9A88-66849FFA9E47@cbfiddle.com> Hi Sergey, I can use System Preferences instead of Finder to avoid problems with pre-existing windows and utility panels covering the test frames. I have also experienced the color panel reappearing in applications run using the java command. I notice there is a directory ~/Library/Saved Application State/net.java.openjdk/cmd.savedState, which contains information about windows, including the color panel and the Java frames that were closed. I do not know how to prevent the color panel from reopening, other than by disabling this feature for the java command. See: https://apple.stackexchange.com/questions/177428/how-to-prevent-one-app-from-saving-restoring-any-saved-state It seems to me that saving information for the java command is a mistake, as it is an application launcher, not a single application. Perhaps the JDK installer should disable this feature. Alan > On Apr 9, 2018, at 4:06 PM, Sergey Bylokhov wrote: > > Hi, Alan. > I just found a few side effects in the test. > - All other tests(actually all java applications) which are executed after the new test will show colorPanel(until it will not be closed manually). > - If the Finder will be opened in full screen(or in the location where the test will show the test windows) then the test will fail. Maybe it is better to use some other application to deactivate the test? Can we implement it using other java application?(you can run the same TestMainKeyWindow.main() and pass some flag to it) > > > On 05/04/2018 16:15, Alan Snyder wrote: >> Thank you for your comments. Here is the updated webrev: >> http://cr.openjdk.java.net/~serb/alans/8194327/webrev.01/ >> Alan >>> On Apr 4, 2018, at 9:34 AM, Sergey Bylokhov >> wrote: >>> >>> Hi, Alan. >>> A few comments about the test: >>> - It is a mac specific and JtregNativeJdk should compile it on mac only >>> - It should close all windows at the end, currently it leaves Finder opened. >>> - it tries to use NSWindowStyleMask/NSWindowStyleMaskTitled which are available in >10.12. We only plan to move to 10.9 soon. So the test should skip it or use NSInteger/NSTitledWindowMask for macOS < MAC_OS_X_VERSION_10_12. >>> - It looks like other tests in JtregNativeJdk.gmk use libtest+Some useful name, I suggest to use the same instead of bugid(same for the test name "Test.java"). >>> BUILD_JDK_JTREG_LIBRARIES_LIBS_libtest819432 >>> >>> On 02/04/2018 19:35, Alan Snyder wrote: >>>> Please review the following change to the macOS AWT. >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194327 >>>> Webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.00/ >>>> The goal of this change is to allow a Java desktop application on macOS to properly coexist with a native utility panel, such as the native color chooser. >>>> The native color chooser is an example of a window that can become the key (focused) window but cannot become the main window. >>>> If the previously active window is a Java frame, it should resign key window status (lose focus), but retain the main window status. >>>> A window that is main but not key does not own the keyboard focus, but it appears active, and if it is using the screen menu bar, >>>> it may be invoked to process a menu item action (if the menu item is not already handled by the key window). >>>> The current macOS AWT does not support this combination of window states. A Java window is either key and main, or neither. >>>> When the color chooser becomes key (obtains focus), the Java frame resigns both key and main status. >>>> This change allows the key window status to be resigned while retaining the main window status, with the appropriate behavior. >>>> Note that with this change, it remains impossible to implement a Java window that behaves like the native color chooser (i.e., can become key but not main). >>>> That would require a much bigger change. >>>> Alan >>> >>> >>> -- >>> Best regards, Sergey. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Tue Apr 10 20:57:30 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 10 Apr 2018 22:57:30 +0200 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <1523359536.4542.2.camel@redhat.com> References: <1523281192.148486.9.camel@redhat.com> <1523359536.4542.2.camel@redhat.com> Message-ID: <485e618c-e6f3-b36f-3201-f6f11fb28ace@oracle.com> On 2018-04-10 13:25, Severin Gehwolf wrote: > Hi Erik, > > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: >> Hello Severin, >> >> I'm ok with this solution for now. > Thanks for the review! > >> Could you please reduce the indentation on line 652. In the build system >> we like 4 spaces for continuation indent [1] > Done. New webrev at: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02 It's not nice, but there's no other way to do it right now. Approved. (I'm working on getting to the point were I can address this in a better way.) /Magnus > > Could someone from awt-dev have a look at this too? Thanks! > > Cheers, > Severin > >> /Erik >> >> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >> >> On 2018-04-09 06:39, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review this build fix for libfontmanager.so. The >>> issue for us is that with some LDFLAGS the build breaks as described in >>> bug JDK-8196218. However, we cannot link to a providing library at >>> build-time since we don't know which one it should be: libawt_headless >>> or libawt_xawt. That has to happen at runtime. The proposed fix filters >>> out relevant linker flags when libfontmanager is being built. More >>> details are in the bug. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/ >>> >>> Testing: I've run this through submit[1] and got the following results. >>> SwingSet2 works fine for me on F27. I'm currently running some more >>> tests on RHEL 7. >>> >>> --------------------- >>> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE. >>> >>> 0 Failed Tests >>> >>> Mach5 Tasks Results Summary >>> >>> NA: 0 >>> UNABLE_TO_RUN: 0 >>> EXECUTED_WITH_FAILURE: 0 >>> KILLED: 0 >>> PASSED: 82 >>> FAILED: 1 >>> Test >>> >>> 1 Failed >>> >>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64- >>> debug-31 SetupFailedException in setup...profile run-test-prebuilt' , >>> return value: 10 >>> -------------------- >>> >>> Not sure what this test failure means. Could somebody at Oracle shed >>> some light on this? >>> >>> Thanks, >>> Severin >> From Sergey.Bylokhov at oracle.com Tue Apr 10 21:51:02 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Apr 2018 14:51:02 -0700 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: References: <1523281192.148486.9.camel@redhat.com> <1523359536.4542.2.camel@redhat.com> Message-ID: <6f11a22e-cf96-24c5-a524-2c82c0b0fc36@oracle.com> LIBS_aix := -lawt_headless, I guess that AIX team should have a similar fix. On 10/04/2018 09:34, Erik Joelsson wrote: > Looks good. Thanks! > > /Erik > > > On 2018-04-10 04:25, Severin Gehwolf wrote: >> Hi Erik, >> >> On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: >>> Hello Severin, >>> >>> I'm ok with this solution for now. >> Thanks for the review! >> >>> Could you please reduce the indentation on line 652. In the build system >>> we like 4 spaces for continuation indent [1] >> Done. New webrev at: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02 >> >> Could someone from awt-dev have a look at this too? Thanks! >> >> Cheers, >> Severin >> >>> /Erik >>> >>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >>> >>> On 2018-04-09 06:39, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> Could somebody please review this build fix for libfontmanager.so. The >>>> issue for us is that with some LDFLAGS the build breaks as described in >>>> bug JDK-8196218. However, we cannot link to a providing library at >>>> build-time since we don't know which one it should be: libawt_headless >>>> or libawt_xawt. That has to happen at runtime. The proposed fix filters >>>> out relevant linker flags when libfontmanager is being built. More >>>> details are in the bug. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 >>>> webrev: >>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/ >>>> >>>> Testing: I've run this through submit[1] and got the following results. >>>> SwingSet2 works fine for me on F27. I'm currently running some more >>>> tests on RHEL 7. >>>> >>>> --------------------- >>>> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds >>>> PASSED. Testing FAILURE. >>>> >>>> 0 Failed Tests >>>> >>>> Mach5 Tasks Results Summary >>>> >>>> NA: 0 >>>> UNABLE_TO_RUN: 0 >>>> EXECUTED_WITH_FAILURE: 0 >>>> KILLED: 0 >>>> PASSED: 82 >>>> FAILED: 1 >>>> Test >>>> >>>> 1 Failed >>>> >>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64- >>>> debug-31 SetupFailedException in setup...profile run-test-prebuilt' , >>>> return value: 10 >>>> -------------------- >>>> >>>> Not sure what this test failure means. Could somebody at Oracle shed >>>> some light on this? >>>> >>>> Thanks, >>>> Severin >>> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Apr 10 21:55:09 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Apr 2018 14:55:09 -0700 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <485e618c-e6f3-b36f-3201-f6f11fb28ace@oracle.com> References: <1523281192.148486.9.camel@redhat.com> <1523359536.4542.2.camel@redhat.com> <485e618c-e6f3-b36f-3201-f6f11fb28ace@oracle.com> Message-ID: <21d3872a-7aeb-3b74-93ea-68b1a0be9bbb@oracle.com> +1 On 10/04/2018 13:57, Magnus Ihse Bursie wrote: > On 2018-04-10 13:25, Severin Gehwolf wrote: >> Hi Erik, >> >> On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: >>> Hello Severin, >>> >>> I'm ok with this solution for now. >> Thanks for the review! >> >>> Could you please reduce the indentation on line 652. In the build system >>> we like 4 spaces for continuation indent [1] >> Done. New webrev at: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02 > It's not nice, but there's no other way to do it right now. Approved. > > (I'm working on getting to the point were I can address this in a better > way.) > > /Magnus >> >> Could someone from awt-dev have a look at this too? Thanks! >> >> Cheers, >> Severin >> >>> /Erik >>> >>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >>> >>> On 2018-04-09 06:39, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> Could somebody please review this build fix for libfontmanager.so. The >>>> issue for us is that with some LDFLAGS the build breaks as described in >>>> bug JDK-8196218. However, we cannot link to a providing library at >>>> build-time since we don't know which one it should be: libawt_headless >>>> or libawt_xawt. That has to happen at runtime. The proposed fix filters >>>> out relevant linker flags when libfontmanager is being built. More >>>> details are in the bug. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 >>>> webrev: >>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/ >>>> >>>> Testing: I've run this through submit[1] and got the following results. >>>> SwingSet2 works fine for me on F27. I'm currently running some more >>>> tests on RHEL 7. >>>> >>>> --------------------- >>>> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds >>>> PASSED. Testing FAILURE. >>>> >>>> 0 Failed Tests >>>> >>>> Mach5 Tasks Results Summary >>>> >>>> NA: 0 >>>> UNABLE_TO_RUN: 0 >>>> EXECUTED_WITH_FAILURE: 0 >>>> KILLED: 0 >>>> PASSED: 82 >>>> FAILED: 1 >>>> Test >>>> >>>> 1 Failed >>>> >>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64- >>>> debug-31 SetupFailedException in setup...profile run-test-prebuilt' , >>>> return value: 10 >>>> -------------------- >>>> >>>> Not sure what this test failure means. Could somebody at Oracle shed >>>> some light on this? >>>> >>>> Thanks, >>>> Severin >>> > -- Best regards, Sergey. From sgehwolf at redhat.com Wed Apr 11 08:17:57 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 11 Apr 2018 10:17:57 +0200 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <6f11a22e-cf96-24c5-a524-2c82c0b0fc36@oracle.com> References: <1523281192.148486.9.camel@redhat.com> <1523359536.4542.2.camel@redhat.com> <6f11a22e-cf96-24c5-a524-2c82c0b0fc36@oracle.com> Message-ID: <1523434677.4440.8.camel@redhat.com> On Tue, 2018-04-10 at 14:51 -0700, Sergey Bylokhov wrote: > LIBS_aix := -lawt_headless, > I guess that AIX team should have a similar fix. Possibly. I have no way of testing it, though. So will leave it to AIX folk to have a look. My experience was that it isn't easily reproducible. Some observations: 1. Run swing app such as SwingSet2 on a headfull system. Since fontmanager will have a link dep on lawt_headless, and awt code loads libawt_xawt (headfull) on a headfull system, both libraries providing symbols needed by libfontmanager will be loaded. Then it depends whether this is a problem on that particular system or not. In my experience this worked on some systems and not on others. 2. Solaris was build-time linking to libawt_headless causing bug 8194870. So build-time linking got removed with that bug. Not sure why that bug is private :( Thanks, Severin > On 10/04/2018 09:34, Erik Joelsson wrote: > > Looks good. Thanks! > > > > /Erik > > > > > > On 2018-04-10 04:25, Severin Gehwolf wrote: > > > Hi Erik, > > > > > > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: > > > > Hello Severin, > > > > > > > > I'm ok with this solution for now. > > > > > > Thanks for the review! > > > > > > > Could you please reduce the indentation on line 652. In the > > > > build system > > > > we like 4 spaces for continuation indent [1] > > > > > > Done. New webrev at: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.0 > > > 2 > > > > > > Could someone from awt-dev have a look at this too? Thanks! > > > > > > Cheers, > > > Severin > > > > > > > /Erik > > > > > > > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.h > > > > tml > > > > > > > > On 2018-04-09 06:39, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Could somebody please review this build fix for > > > > > libfontmanager.so. The > > > > > issue for us is that with some LDFLAGS the build breaks as > > > > > described in > > > > > bug JDK-8196218. However, we cannot link to a providing > > > > > library at > > > > > build-time since we don't know which one it should be: > > > > > libawt_headless > > > > > or libawt_xawt. That has to happen at runtime. The proposed > > > > > fix filters > > > > > out relevant linker flags when libfontmanager is being built. > > > > > More > > > > > details are in the bug. > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 > > > > > webrev: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webr > > > > > ev.01/ > > > > > > > > > > Testing: I've run this through submit[1] and got the > > > > > following results. > > > > > SwingSet2 works fine for me on F27. I'm currently running > > > > > some more > > > > > tests on RHEL 7. > > > > > > > > > > --------------------- > > > > > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: > > > > > Builds > > > > > PASSED. Testing FAILURE. > > > > > > > > > > 0 Failed Tests > > > > > > > > > > Mach5 Tasks Results Summary > > > > > > > > > > NA: 0 > > > > > UNABLE_TO_RUN: 0 > > > > > EXECUTED_WITH_FAILURE: 0 > > > > > KILLED: 0 > > > > > PASSED: 82 > > > > > FAILED: 1 > > > > > Test > > > > > > > > > > 1 Failed > > > > > > > > > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2- > > > > > windows-x64- > > > > > debug-31 SetupFailedException in setup...profile run-test- > > > > > prebuilt' , > > > > > return value: 10 > > > > > -------------------- > > > > > > > > > > Not sure what this test failure means. Could somebody at > > > > > Oracle shed > > > > > some light on this? > > > > > > > > > > Thanks, > > > > > Severin > > From sgehwolf at redhat.com Wed Apr 11 09:39:27 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 11 Apr 2018 11:39:27 +0200 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: References: <1523281192.148486.9.camel@redhat.com> <1523359536.4542.2.camel@redhat.com> Message-ID: <1523439567.4440.17.camel@redhat.com> On Tue, 2018-04-10 at 09:34 -0700, Erik Joelsson wrote: > Looks good. Thanks! Thanks, Erik. Cheers, Severin > /Erik > > > On 2018-04-10 04:25, Severin Gehwolf wrote: > > Hi Erik, > > > > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: > > > Hello Severin, > > > > > > I'm ok with this solution for now. > > > > Thanks for the review! > > > > > Could you please reduce the indentation on line 652. In the build system > > > we like 4 spaces for continuation indent [1] > > > > Done. New webrev at: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02 > > > > Could someone from awt-dev have a look at this too? Thanks! > > > > Cheers, > > Severin > > > > > /Erik > > > > > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.html > > > > > > On 2018-04-09 06:39, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could somebody please review this build fix for libfontmanager.so. The > > > > issue for us is that with some LDFLAGS the build breaks as described in > > > > bug JDK-8196218. However, we cannot link to a providing library at > > > > build-time since we don't know which one it should be: libawt_headless > > > > or libawt_xawt. That has to happen at runtime. The proposed fix filters > > > > out relevant linker flags when libfontmanager is being built. More > > > > details are in the bug. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/ > > > > > > > > Testing: I've run this through submit[1] and got the following results. > > > > SwingSet2 works fine for me on F27. I'm currently running some more > > > > tests on RHEL 7. > > > > > > > > --------------------- > > > > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE. > > > > > > > > 0 Failed Tests > > > > > > > > Mach5 Tasks Results Summary > > > > > > > > NA: 0 > > > > UNABLE_TO_RUN: 0 > > > > EXECUTED_WITH_FAILURE: 0 > > > > KILLED: 0 > > > > PASSED: 82 > > > > FAILED: 1 > > > > Test > > > > > > > > 1 Failed > > > > > > > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64- > > > > debug-31 SetupFailedException in setup...profile run-test-prebuilt' , > > > > return value: 10 > > > > -------------------- > > > > > > > > Not sure what this test failure means. Could somebody at Oracle shed > > > > some light on this? > > > > > > > > Thanks, > > > > Severin > > From sgehwolf at redhat.com Wed Apr 11 09:41:39 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 11 Apr 2018 11:41:39 +0200 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <485e618c-e6f3-b36f-3201-f6f11fb28ace@oracle.com> References: <1523281192.148486.9.camel@redhat.com> <1523359536.4542.2.camel@redhat.com> <485e618c-e6f3-b36f-3201-f6f11fb28ace@oracle.com> Message-ID: <1523439699.4440.19.camel@redhat.com> Hi Magnus, On Tue, 2018-04-10 at 22:57 +0200, Magnus Ihse Bursie wrote: > On 2018-04-10 13:25, Severin Gehwolf wrote: > > Hi Erik, > > > > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: > > > Hello Severin, > > > > > > I'm ok with this solution for now. > > > > Thanks for the review! > > > > > Could you please reduce the indentation on line 652. In the build > > > system > > > we like 4 spaces for continuation indent [1] > > > > Done. New webrev at: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02 > > It's not nice, but there's no other way to do it right now. Approved. Thanks for the review! Cheers, Severin > (I'm working on getting to the point were I can address this in a > better > way.) > > /Magnus > > > > Could someone from awt-dev have a look at this too? Thanks! > > > > Cheers, > > Severin > > > > > /Erik > > > > > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.htm > > > l > > > > > > On 2018-04-09 06:39, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could somebody please review this build fix for > > > > libfontmanager.so. The > > > > issue for us is that with some LDFLAGS the build breaks as > > > > described in > > > > bug JDK-8196218. However, we cannot link to a providing library > > > > at > > > > build-time since we don't know which one it should be: > > > > libawt_headless > > > > or libawt_xawt. That has to happen at runtime. The proposed fix > > > > filters > > > > out relevant linker flags when libfontmanager is being built. > > > > More > > > > details are in the bug. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-819651 > > > > 6/webrev.01/ > > > > > > > > Testing: I've run this through submit[1] and got the following > > > > results. > > > > SwingSet2 works fine for me on F27. I'm currently running some > > > > more > > > > tests on RHEL 7. > > > > > > > > --------------------- > > > > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: > > > > Builds PASSED. Testing FAILURE. > > > > > > > > 0 Failed Tests > > > > > > > > Mach5 Tasks Results Summary > > > > > > > > NA: 0 > > > > UNABLE_TO_RUN: 0 > > > > EXECUTED_WITH_FAILURE: 0 > > > > KILLED: 0 > > > > PASSED: 82 > > > > FAILED: 1 > > > > Test > > > > > > > > 1 Failed > > > > > > > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2- > > > > windows-x64- > > > > debug-31 SetupFailedException in setup...profile run-test- > > > > prebuilt' , > > > > return value: 10 > > > > -------------------- > > > > > > > > Not sure what this test failure means. Could somebody at Oracle > > > > shed > > > > some light on this? > > > > > > > > Thanks, > > > > Severin > > From denis.fokin at gmail.com Wed Apr 11 14:44:12 2018 From: denis.fokin at gmail.com (Denis Fokin) Date: Wed, 11 Apr 2018 14:44:12 +0000 Subject: [11] JDK-8181910: [macos] Support dark title bars on macOS In-Reply-To: References: <9e2fcb3c-425e-6ad7-7778-5a297902df64@oracle.com> Message-ID: Hi Sergey, can I just approve any modifications and usage of the patch? I am absolutely ok with pushing or improving the fix by Shashidhara. __ Thank you, Denis On Tue, Apr 3, 2018 at 10:50 PM Sergey Bylokhov wrote: > Yes, this fix can be contributed by someone from the JB. > > On 03/04/2018 06:48, Hendrik Schreiber wrote: > > Hey, > > > > I was wondering how this is going. Are you guys still stuck, waiting for > Denis to help out? > > > > -hendrik > > > > > >> On Mar 30, 2018, at 07:32, shashidhara.veerabhadraiah at oracle.com wrote: > >> > >> Sure. I did had a confusion to put for review though but did not know > what to do and felt not to keep waiting. Thanks for the direction Sergey. > >> > >> Thanks and regards, > >> Shashi > >> > >> > >> On 29/03/18 7:45 PM, Sergey Bylokhov wrote: > >>> Unfortunately we cannot accept the patch which were suggested in the > description of the bug. Initially it was implemented in JetBrains JRE. We > can accept it if someone from the JetBrains will contribute it. > >>> > >>> Maybe Denis who is author of the fix can help? > >>> > >>> On 28/03/2018 02:29, Shashidhara Veerabhadraiah wrote: > >>>> Hi All, Please review an enhancement for the below bug: > >>>> > >>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8181910 > >>>> > >>>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8181910/webrev.00/ > >>>> > >>>> This utilizes the NSAppearance to set the appearance theme to dark or > light. > >>>> > >>>> Thanks and regards, > >>>> > >>>> Shashi > >>>> > >>> > >>> > >> > > > > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Apr 11 15:40:27 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Apr 2018 08:40:27 -0700 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <1523434677.4440.8.camel@redhat.com> References: <1523281192.148486.9.camel@redhat.com> <1523359536.4542.2.camel@redhat.com> <6f11a22e-cf96-24c5-a524-2c82c0b0fc36@oracle.com> <1523434677.4440.8.camel@redhat.com> Message-ID: <8c1b2b59-16f8-9507-391d-c03a06c765ec@oracle.com> Yes, I think this should be removed for AIX as we have done for Solaris + Linux, and I could have done that but I also had no way to test it .. without that capability I ran more risk of breaking AIX than fixing a problem that apparently hasn't been seen there. I am not sure if *headful* tests are regularly run on AIX, although email from earlier this week from IBM offering to contribute some input method support for AIX strongly suggests that it is of interest :-) -phil. On 04/11/2018 01:17 AM, Severin Gehwolf wrote: > On Tue, 2018-04-10 at 14:51 -0700, Sergey Bylokhov wrote: >> LIBS_aix := -lawt_headless, >> I guess that AIX team should have a similar fix. > Possibly. I have no way of testing it, though. So will leave it to AIX > folk to have a look. My experience was that it isn't easily > reproducible. Some observations: > > 1. Run swing app such as SwingSet2 on a headfull system. Since > fontmanager will have a link dep on lawt_headless, and awt code > loads libawt_xawt (headfull) on a headfull system, both libraries > providing symbols needed by libfontmanager will be loaded. Then it > depends whether this is a problem on that particular system or not. > In my experience this worked on some systems and not on others. > 2. Solaris was build-time linking to libawt_headless causing bug > 8194870. So build-time linking got removed with that bug. Not sure > why that bug is private :( > > Thanks, > Severin > >> On 10/04/2018 09:34, Erik Joelsson wrote: >>> Looks good. Thanks! >>> >>> /Erik >>> >>> >>> On 2018-04-10 04:25, Severin Gehwolf wrote: >>>> Hi Erik, >>>> >>>> On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: >>>>> Hello Severin, >>>>> >>>>> I'm ok with this solution for now. >>>> Thanks for the review! >>>> >>>>> Could you please reduce the indentation on line 652. In the >>>>> build system >>>>> we like 4 spaces for continuation indent [1] >>>> Done. New webrev at: >>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.0 >>>> 2 >>>> >>>> Could someone from awt-dev have a look at this too? Thanks! >>>> >>>> Cheers, >>>> Severin >>>> >>>>> /Erik >>>>> >>>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.h >>>>> tml >>>>> >>>>> On 2018-04-09 06:39, Severin Gehwolf wrote: >>>>>> Hi, >>>>>> >>>>>> Could somebody please review this build fix for >>>>>> libfontmanager.so. The >>>>>> issue for us is that with some LDFLAGS the build breaks as >>>>>> described in >>>>>> bug JDK-8196218. However, we cannot link to a providing >>>>>> library at >>>>>> build-time since we don't know which one it should be: >>>>>> libawt_headless >>>>>> or libawt_xawt. That has to happen at runtime. The proposed >>>>>> fix filters >>>>>> out relevant linker flags when libfontmanager is being built. >>>>>> More >>>>>> details are in the bug. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webr >>>>>> ev.01/ >>>>>> >>>>>> Testing: I've run this through submit[1] and got the >>>>>> following results. >>>>>> SwingSet2 works fine for me on F27. I'm currently running >>>>>> some more >>>>>> tests on RHEL 7. >>>>>> >>>>>> --------------------- >>>>>> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: >>>>>> Builds >>>>>> PASSED. Testing FAILURE. >>>>>> >>>>>> 0 Failed Tests >>>>>> >>>>>> Mach5 Tasks Results Summary >>>>>> >>>>>> NA: 0 >>>>>> UNABLE_TO_RUN: 0 >>>>>> EXECUTED_WITH_FAILURE: 0 >>>>>> KILLED: 0 >>>>>> PASSED: 82 >>>>>> FAILED: 1 >>>>>> Test >>>>>> >>>>>> 1 Failed >>>>>> >>>>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2- >>>>>> windows-x64- >>>>>> debug-31 SetupFailedException in setup...profile run-test- >>>>>> prebuilt' , >>>>>> return value: 10 >>>>>> -------------------- >>>>>> >>>>>> Not sure what this test failure means. Could somebody at >>>>>> Oracle shed >>>>>> some light on this? >>>>>> >>>>>> Thanks, >>>>>> Severin >> From philip.race at oracle.com Wed Apr 11 16:14:31 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Apr 2018 09:14:31 -0700 Subject: [11] JDK-8181910: [macos] Support dark title bars on macOS In-Reply-To: References: <9e2fcb3c-425e-6ad7-7778-5a297902df64@oracle.com> Message-ID: I think that should be sufficient. -phil. On 4/11/2018 7:44 AM, Denis Fokin wrote: > Hi Sergey, > > can I just approve any modifications and usage of the patch? I am > absolutely ok with pushing or improving the fix by?Shashidhara. > > __ > Thank you, > ? ? Denis > > On Tue, Apr 3, 2018 at 10:50 PM Sergey Bylokhov > > wrote: > > Yes, this fix can be contributed by someone from the JB. > > On 03/04/2018 06:48, Hendrik Schreiber wrote: > > Hey, > > > > I was wondering how this is going. Are you guys still stuck, > waiting for Denis to help out? > > > > -hendrik > > > > > >> On Mar 30, 2018, at 07:32, > shashidhara.veerabhadraiah at oracle.com > wrote: > >> > >> Sure. I did had a confusion to put for review though but did > not know what to do and felt not to keep waiting. Thanks for the > direction Sergey. > >> > >> Thanks and regards, > >> Shashi > >> > >> > >> On 29/03/18 7:45 PM, Sergey Bylokhov wrote: > >>> Unfortunately we cannot accept the patch which were suggested > in the description of the bug. Initially it was implemented in > JetBrains JRE. We can accept it if someone from the JetBrains will > contribute it. > >>> > >>> Maybe Denis who is author of the fix can help? > >>> > >>> On 28/03/2018 02:29, Shashidhara Veerabhadraiah wrote: > >>>> Hi All, Please review an enhancement for the below bug: > >>>> > >>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8181910 > >>>> > >>>> Webrev: > http://cr.openjdk.java.net/~sveerabhadra/8181910/webrev.00/ > > >>>> > >>>> This utilizes the NSAppearance to set the appearance theme to > dark or light. > >>>> > >>>> Thanks and regards, > >>>> > >>>> Shashi > >>>> > >>> > >>> > >> > > > > > -- > Best regards, Sergey. > From alexey.ivanov at oracle.com Wed Apr 11 18:06:08 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 11 Apr 2018 19:06:08 +0100 Subject: [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 In-Reply-To: <5ede620b-7833-5124-c9ed-7cc61a7e3774@oracle.com> References: <5ede620b-7833-5124-c9ed-7cc61a7e3774@oracle.com> Message-ID: Thank you, Sergey, for your review. Any other volunteers? Thanks, Alexey On 05/04/2018 23:56, Sergey Bylokhov wrote: > Looks fine. > > On 05/04/2018 15:39, Alexey Ivanov wrote: >> Hello, >> >> Could you please review the fix for jdk11? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8199627 >> webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/ >> >> >> Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1] >> >> Java already supports "Per-Monitor v1" mode. This change extends High >> DPI support in Java: in addition to element [2], a new >> element [3] is added to Java launcher manifest. The >> element is recognized by Windows 10 v1607 and above, >> PerMonitorV2 value is supported by Windows 10 v1703 and above. >> >> The most notable change for Java applications is that window title >> bar is scaled correctly when application window moves from one >> monitor to another or the scaling changes. >> >> >> When building, manifest tool generates warning for unknown >> element in manifest. It is because an older Windows >> SDK is used to build JDK which does not know about an element that >> was added later. The build succeeds despite the warning. >> >> >> Thank you in advance. >> >> Regards, >> Alexey >> >> [1] >> https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ >> >> >> [2] >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware >> >> >> [3] >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness >> >> > > From philip.race at oracle.com Wed Apr 11 18:32:12 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Apr 2018 11:32:12 -0700 Subject: [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 In-Reply-To: References: <5ede620b-7833-5124-c9ed-7cc61a7e3774@oracle.com> Message-ID: <7e662873-b007-9fee-a26b-60cfb9584fc4@oracle.com> +1 -phil On 04/11/2018 11:06 AM, Alexey Ivanov wrote: > Thank you, Sergey, for your review. > > Any other volunteers? > > > Thanks, > Alexey > > On 05/04/2018 23:56, Sergey Bylokhov wrote: >> Looks fine. >> >> On 05/04/2018 15:39, Alexey Ivanov wrote: >>> Hello, >>> >>> Could you please review the fix for jdk11? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8199627 >>> webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/ >>> >>> >>> Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1] >>> >>> Java already supports "Per-Monitor v1" mode. This change extends >>> High DPI support in Java: in addition to element [2], a >>> new element [3] is added to Java launcher manifest. >>> The element is recognized by Windows 10 v1607 and >>> above, PerMonitorV2 value is supported by Windows 10 v1703 and above. >>> >>> The most notable change for Java applications is that window title >>> bar is scaled correctly when application window moves from one >>> monitor to another or the scaling changes. >>> >>> >>> When building, manifest tool generates warning for unknown >>> element in manifest. It is because an older Windows >>> SDK is used to build JDK which does not know about an element that >>> was added later. The build succeeds despite the warning. >>> >>> >>> Thank you in advance. >>> >>> Regards, >>> Alexey >>> >>> [1] >>> https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ >>> >>> >>> [2] >>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware >>> >>> >>> [3] >>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness >>> >>> >> >> > From Sergey.Bylokhov at oracle.com Wed Apr 11 22:06:28 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 11 Apr 2018 15:06:28 -0700 Subject: [11] JDK-8181910: [macos] Support dark title bars on macOS In-Reply-To: References: <9e2fcb3c-425e-6ad7-7778-5a297902df64@oracle.com> Message-ID: <81ed89d6-0d65-f2ca-d565-488466050634@oracle.com> Thank you, the fix looks fine. On 11/04/2018 07:44, Denis Fokin wrote: > Hi Sergey, > > can I just approve any modifications and usage of the patch? I am > absolutely ok with pushing or improving the fix by?Shashidhara. > > __ > Thank you, > ? ? Denis > > On Tue, Apr 3, 2018 at 10:50 PM Sergey Bylokhov > > wrote: > > Yes, this fix can be contributed by someone from the JB. > > On 03/04/2018 06:48, Hendrik Schreiber wrote: > > Hey, > > > > I was wondering how this is going. Are you guys still stuck, > waiting for Denis to help out? > > > > -hendrik > > > > > >> On Mar 30, 2018, at 07:32, shashidhara.veerabhadraiah at oracle.com > wrote: > >> > >> Sure. I did had a confusion to put for review though but did not > know what to do and felt not to keep waiting. Thanks for the > direction Sergey. > >> > >> Thanks and regards, > >> Shashi > >> > >> > >> On 29/03/18 7:45 PM, Sergey Bylokhov wrote: > >>> Unfortunately we cannot accept the patch which were suggested > in the description of the bug. Initially it was implemented in > JetBrains JRE. We can accept it if someone from the JetBrains will > contribute it. > >>> > >>> Maybe Denis who is author of the fix can help? > >>> > >>> On 28/03/2018 02:29, Shashidhara Veerabhadraiah wrote: > >>>> Hi All, Please review an enhancement for the below bug: > >>>> > >>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8181910 > >>>> > >>>> Webrev: > http://cr.openjdk.java.net/~sveerabhadra/8181910/webrev.00/ > >>>> > >>>> This utilizes the NSAppearance to set the appearance theme to > dark or light. > >>>> > >>>> Thanks and regards, > >>>> > >>>> Shashi > >>>> > >>> > >>> > >> > > > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Thu Apr 12 04:26:25 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Wed, 11 Apr 2018 21:26:25 -0700 (PDT) Subject: [11] JDK-8181910: [macos] Support dark title bars on macOS In-Reply-To: References: <9e2fcb3c-425e-6ad7-7778-5a297902df64@oracle.com> Message-ID: <20ff5ef0-b5c4-4b44-8d13-028916817e5c@default> Thank you Denis and Phil!! -shashi -----Original Message----- From: Phil Race Sent: Wednesday, April 11, 2018 9:45 PM To: Denis Fokin ; Sergey Bylokhov Cc: awt-dev at openjdk.java.net Subject: Re: [11] JDK-8181910: [macos] Support dark title bars on macOS I think that should be sufficient. -phil. On 4/11/2018 7:44 AM, Denis Fokin wrote: > Hi Sergey, > > can I just approve any modifications and usage of the patch? I am > absolutely ok with pushing or improving the fix by?Shashidhara. > > __ > Thank you, > ? ? Denis > > On Tue, Apr 3, 2018 at 10:50 PM Sergey Bylokhov > > wrote: > > Yes, this fix can be contributed by someone from the JB. > > On 03/04/2018 06:48, Hendrik Schreiber wrote: > > Hey, > > > > I was wondering how this is going. Are you guys still stuck, > waiting for Denis to help out? > > > > -hendrik > > > > > >> On Mar 30, 2018, at 07:32, > shashidhara.veerabhadraiah at oracle.com > wrote: > >> > >> Sure. I did had a confusion to put for review though but did > not know what to do and felt not to keep waiting. Thanks for the > direction Sergey. > >> > >> Thanks and regards, > >> Shashi > >> > >> > >> On 29/03/18 7:45 PM, Sergey Bylokhov wrote: > >>> Unfortunately we cannot accept the patch which were suggested > in the description of the bug. Initially it was implemented in > JetBrains JRE. We can accept it if someone from the JetBrains will > contribute it. > >>> > >>> Maybe Denis who is author of the fix can help? > >>> > >>> On 28/03/2018 02:29, Shashidhara Veerabhadraiah wrote: > >>>> Hi All, Please review an enhancement for the below bug: > >>>> > >>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8181910 > >>>> > >>>> Webrev: > http://cr.openjdk.java.net/~sveerabhadra/8181910/webrev.00/ > > >>>> > >>>> This utilizes the NSAppearance to set the appearance theme to > dark or light. > >>>> > >>>> Thanks and regards, > >>>> > >>>> Shashi > >>>> > >>> > >>> > >> > > > > > -- > Best regards, Sergey. > From shashidhara.veerabhadraiah at oracle.com Thu Apr 12 04:30:20 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Wed, 11 Apr 2018 21:30:20 -0700 (PDT) Subject: [11] JDK-8181910: [macos] Support dark title bars on macOS In-Reply-To: <81ed89d6-0d65-f2ca-d565-488466050634@oracle.com> References: <9e2fcb3c-425e-6ad7-7778-5a297902df64@oracle.com> <81ed89d6-0d65-f2ca-d565-488466050634@oracle.com> Message-ID: <3a7be52c-a086-4c2f-a2f8-2f52bc654269@default> Thank you Sergey for the review. Denis, Please let me know if you have any comments on the changes. Thanks and regards, Shashi -----Original Message----- From: Sergey Bylokhov Sent: Thursday, April 12, 2018 3:36 AM To: Denis Fokin Cc: Hendrik Schreiber ; Shashidhara Veerabhadraiah ; awt-dev at openjdk.java.net Subject: Re: [11] JDK-8181910: [macos] Support dark title bars on macOS Thank you, the fix looks fine. On 11/04/2018 07:44, Denis Fokin wrote: > Hi Sergey, > > can I just approve any modifications and usage of the patch? I am > absolutely ok with pushing or improving the fix by?Shashidhara. > > __ > Thank you, > ? ? Denis > > On Tue, Apr 3, 2018 at 10:50 PM Sergey Bylokhov > > wrote: > > Yes, this fix can be contributed by someone from the JB. > > On 03/04/2018 06:48, Hendrik Schreiber wrote: > > Hey, > > > > I was wondering how this is going. Are you guys still stuck, > waiting for Denis to help out? > > > > -hendrik > > > > > >> On Mar 30, 2018, at 07:32, shashidhara.veerabhadraiah at oracle.com > wrote: > >> > >> Sure. I did had a confusion to put for review though but did not > know what to do and felt not to keep waiting. Thanks for the > direction Sergey. > >> > >> Thanks and regards, > >> Shashi > >> > >> > >> On 29/03/18 7:45 PM, Sergey Bylokhov wrote: > >>> Unfortunately we cannot accept the patch which were suggested > in the description of the bug. Initially it was implemented in > JetBrains JRE. We can accept it if someone from the JetBrains will > contribute it. > >>> > >>> Maybe Denis who is author of the fix can help? > >>> > >>> On 28/03/2018 02:29, Shashidhara Veerabhadraiah wrote: > >>>> Hi All, Please review an enhancement for the below bug: > >>>> > >>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8181910 > >>>> > >>>> Webrev: > http://cr.openjdk.java.net/~sveerabhadra/8181910/webrev.00/ > >>>> > >>>> This utilizes the NSAppearance to set the appearance theme to > dark or light. > >>>> > >>>> Thanks and regards, > >>>> > >>>> Shashi > >>>> > >>> > >>> > >> > > > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From volker.simonis at gmail.com Fri Apr 13 07:03:28 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Apr 2018 09:03:28 +0200 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <1523434677.4440.8.camel@redhat.com> References: <1523281192.148486.9.camel@redhat.com> <1523359536.4542.2.camel@redhat.com> <6f11a22e-cf96-24c5-a524-2c82c0b0fc36@oracle.com> <1523434677.4440.8.camel@redhat.com> Message-ID: Hi Severin, I'm currently looking at the AIX-side of this bug. The problem I see with your solution is that it uses LDFLAGS (which is generic) to filter out Linux specific linker flags. If we would extend this to AIX, we would have to add yet another substitution for AIX which filters out "-Wl,bernotok". This is not beautiful and gets uglier with every new platform. But as this change has already been pushed and because (fortunately) on AIX options which come later on the command line take precedence over earlier ones I can easily fix this with a specific LDFLAGS_aix setting. I've opened "8201524: [AIX] Don't link libfontmanager against libawt_headless" [1] for it and I'll send out a new RFR for it soon. Regards, Volker [1] https://bugs.openjdk.java.net/browse/JDK-8201524 On Wed, Apr 11, 2018 at 10:17 AM, Severin Gehwolf wrote: > On Tue, 2018-04-10 at 14:51 -0700, Sergey Bylokhov wrote: >> LIBS_aix := -lawt_headless, >> I guess that AIX team should have a similar fix. > > Possibly. I have no way of testing it, though. So will leave it to AIX > folk to have a look. My experience was that it isn't easily > reproducible. Some observations: > > 1. Run swing app such as SwingSet2 on a headfull system. Since > fontmanager will have a link dep on lawt_headless, and awt code > loads libawt_xawt (headfull) on a headfull system, both libraries > providing symbols needed by libfontmanager will be loaded. Then it > depends whether this is a problem on that particular system or not. > In my experience this worked on some systems and not on others. > 2. Solaris was build-time linking to libawt_headless causing bug > 8194870. So build-time linking got removed with that bug. Not sure > why that bug is private :( > > Thanks, > Severin > >> On 10/04/2018 09:34, Erik Joelsson wrote: >> > Looks good. Thanks! >> > >> > /Erik >> > >> > >> > On 2018-04-10 04:25, Severin Gehwolf wrote: >> > > Hi Erik, >> > > >> > > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: >> > > > Hello Severin, >> > > > >> > > > I'm ok with this solution for now. >> > > >> > > Thanks for the review! >> > > >> > > > Could you please reduce the indentation on line 652. In the >> > > > build system >> > > > we like 4 spaces for continuation indent [1] >> > > >> > > Done. New webrev at: >> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.0 >> > > 2 >> > > >> > > Could someone from awt-dev have a look at this too? Thanks! >> > > >> > > Cheers, >> > > Severin >> > > >> > > > /Erik >> > > > >> > > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.h >> > > > tml >> > > > >> > > > On 2018-04-09 06:39, Severin Gehwolf wrote: >> > > > > Hi, >> > > > > >> > > > > Could somebody please review this build fix for >> > > > > libfontmanager.so. The >> > > > > issue for us is that with some LDFLAGS the build breaks as >> > > > > described in >> > > > > bug JDK-8196218. However, we cannot link to a providing >> > > > > library at >> > > > > build-time since we don't know which one it should be: >> > > > > libawt_headless >> > > > > or libawt_xawt. That has to happen at runtime. The proposed >> > > > > fix filters >> > > > > out relevant linker flags when libfontmanager is being built. >> > > > > More >> > > > > details are in the bug. >> > > > > >> > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 >> > > > > webrev: >> > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webr >> > > > > ev.01/ >> > > > > >> > > > > Testing: I've run this through submit[1] and got the >> > > > > following results. >> > > > > SwingSet2 works fine for me on F27. I'm currently running >> > > > > some more >> > > > > tests on RHEL 7. >> > > > > >> > > > > --------------------- >> > > > > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: >> > > > > Builds >> > > > > PASSED. Testing FAILURE. >> > > > > >> > > > > 0 Failed Tests >> > > > > >> > > > > Mach5 Tasks Results Summary >> > > > > >> > > > > NA: 0 >> > > > > UNABLE_TO_RUN: 0 >> > > > > EXECUTED_WITH_FAILURE: 0 >> > > > > KILLED: 0 >> > > > > PASSED: 82 >> > > > > FAILED: 1 >> > > > > Test >> > > > > >> > > > > 1 Failed >> > > > > >> > > > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2- >> > > > > windows-x64- >> > > > > debug-31 SetupFailedException in setup...profile run-test- >> > > > > prebuilt' , >> > > > > return value: 10 >> > > > > -------------------- >> > > > > >> > > > > Not sure what this test failure means. Could somebody at >> > > > > Oracle shed >> > > > > some light on this? >> > > > > >> > > > > Thanks, >> > > > > Severin >> >> From sgehwolf at redhat.com Fri Apr 13 07:33:10 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 13 Apr 2018 09:33:10 +0200 Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: References: <1523281192.148486.9.camel@redhat.com> <1523359536.4542.2.camel@redhat.com> <6f11a22e-cf96-24c5-a524-2c82c0b0fc36@oracle.com> <1523434677.4440.8.camel@redhat.com> Message-ID: <1523604790.4177.5.camel@redhat.com> Hi Volker, On Fri, 2018-04-13 at 09:03 +0200, Volker Simonis wrote: > Hi Severin, > > I'm currently looking at the AIX-side of this bug. > > The problem I see with your solution is that it uses LDFLAGS (which is > generic) to filter out Linux specific linker flags. If we would extend > this to AIX, we would have to add yet another substitution for AIX > which filters out "-Wl,bernotok". This is not beautiful and gets > uglier with every new platform. Right. Note, though, that Magnus seems to be working on a more comprehensive solution to this: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021625.html FWIW, the substitution for -Wl,-z,defs was there in LDFLAGS all along (it was missing the other syntax). Not sure if -Wl,-z,defs is generic enough to warrant it being on LDFLAGS directly, not LDFLAGS_linux or some other OS specific variant. Either way, that's the model I've followed. Thanks, Severin > But as this change has already been pushed and because (fortunately) > on AIX options which come later on the command line take precedence > over earlier ones I can easily fix this with a specific LDFLAGS_aix > setting. I've opened "8201524: [AIX] Don't link libfontmanager against > libawt_headless" [1] for it and I'll send out a new RFR for it soon. > > Regards, > Volker > > [1] https://bugs.openjdk.java.net/browse/JDK-8201524 > > > On Wed, Apr 11, 2018 at 10:17 AM, Severin Gehwolf wrote: > > On Tue, 2018-04-10 at 14:51 -0700, Sergey Bylokhov wrote: > > > LIBS_aix := -lawt_headless, > > > I guess that AIX team should have a similar fix. > > > > Possibly. I have no way of testing it, though. So will leave it to AIX > > folk to have a look. My experience was that it isn't easily > > reproducible. Some observations: > > > > 1. Run swing app such as SwingSet2 on a headfull system. Since > > fontmanager will have a link dep on lawt_headless, and awt code > > loads libawt_xawt (headfull) on a headfull system, both libraries > > providing symbols needed by libfontmanager will be loaded. Then it > > depends whether this is a problem on that particular system or not. > > In my experience this worked on some systems and not on others. > > 2. Solaris was build-time linking to libawt_headless causing bug > > 8194870. So build-time linking got removed with that bug. Not sure > > why that bug is private :( > > > > Thanks, > > Severin > > > > > On 10/04/2018 09:34, Erik Joelsson wrote: > > > > Looks good. Thanks! > > > > > > > > /Erik > > > > > > > > > > > > On 2018-04-10 04:25, Severin Gehwolf wrote: > > > > > Hi Erik, > > > > > > > > > > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: > > > > > > Hello Severin, > > > > > > > > > > > > I'm ok with this solution for now. > > > > > > > > > > Thanks for the review! > > > > > > > > > > > Could you please reduce the indentation on line 652. In the > > > > > > build system > > > > > > we like 4 spaces for continuation indent [1] > > > > > > > > > > Done. New webrev at: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.0 > > > > > 2 > > > > > > > > > > Could someone from awt-dev have a look at this too? Thanks! > > > > > > > > > > Cheers, > > > > > Severin > > > > > > > > > > > /Erik > > > > > > > > > > > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.h > > > > > > tml > > > > > > > > > > > > On 2018-04-09 06:39, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Could somebody please review this build fix for > > > > > > > libfontmanager.so. The > > > > > > > issue for us is that with some LDFLAGS the build breaks as > > > > > > > described in > > > > > > > bug JDK-8196218. However, we cannot link to a providing > > > > > > > library at > > > > > > > build-time since we don't know which one it should be: > > > > > > > libawt_headless > > > > > > > or libawt_xawt. That has to happen at runtime. The proposed > > > > > > > fix filters > > > > > > > out relevant linker flags when libfontmanager is being built. > > > > > > > More > > > > > > > details are in the bug. > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 > > > > > > > webrev: > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webr > > > > > > > ev.01/ > > > > > > > > > > > > > > Testing: I've run this through submit[1] and got the > > > > > > > following results. > > > > > > > SwingSet2 works fine for me on F27. I'm currently running > > > > > > > some more > > > > > > > tests on RHEL 7. > > > > > > > > > > > > > > --------------------- > > > > > > > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: > > > > > > > Builds > > > > > > > PASSED. Testing FAILURE. > > > > > > > > > > > > > > 0 Failed Tests > > > > > > > > > > > > > > Mach5 Tasks Results Summary > > > > > > > > > > > > > > NA: 0 > > > > > > > UNABLE_TO_RUN: 0 > > > > > > > EXECUTED_WITH_FAILURE: 0 > > > > > > > KILLED: 0 > > > > > > > PASSED: 82 > > > > > > > FAILED: 1 > > > > > > > Test > > > > > > > > > > > > > > 1 Failed > > > > > > > > > > > > > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2- > > > > > > > windows-x64- > > > > > > > debug-31 SetupFailedException in setup...profile run-test- > > > > > > > prebuilt' , > > > > > > > return value: 10 > > > > > > > -------------------- > > > > > > > > > > > > > > Not sure what this test failure means. Could somebody at > > > > > > > Oracle shed > > > > > > > some light on this? > > > > > > > > > > > > > > Thanks, > > > > > > > Severin > > > > > > From denis.fokin at gmail.com Fri Apr 13 10:28:10 2018 From: denis.fokin at gmail.com (Denis Fokin) Date: Fri, 13 Apr 2018 10:28:10 +0000 Subject: [11] JDK-8181910: [macos] Support dark title bars on macOS In-Reply-To: <3a7be52c-a086-4c2f-a2f8-2f52bc654269@default> References: <9e2fcb3c-425e-6ad7-7778-5a297902df64@oracle.com> <81ed89d6-0d65-f2ca-d565-488466050634@oracle.com> <3a7be52c-a086-4c2f-a2f8-2f52bc654269@default> Message-ID: Hi Shashi, Thank you for the fix, it looks fine. Thank you, Denis. On Thu, Apr 12, 2018 at 7:30 AM Shashidhara Veerabhadraiah < shashidhara.veerabhadraiah at oracle.com> wrote: > Thank you Sergey for the review. > > Denis, Please let me know if you have any comments on the changes. > > Thanks and regards, > Shashi > > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, April 12, 2018 3:36 AM > To: Denis Fokin > Cc: Hendrik Schreiber ; Shashidhara Veerabhadraiah < > shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net > Subject: Re: [11] JDK-8181910: [macos] Support dark title bars > on macOS > > Thank you, the fix looks fine. > > On 11/04/2018 07:44, Denis Fokin wrote: > > Hi Sergey, > > > > can I just approve any modifications and usage of the patch? I am > > absolutely ok with pushing or improving the fix by Shashidhara. > > > > __ > > Thank you, > > Denis > > > > On Tue, Apr 3, 2018 at 10:50 PM Sergey Bylokhov > > > wrote: > > > > Yes, this fix can be contributed by someone from the JB. > > > > On 03/04/2018 06:48, Hendrik Schreiber wrote: > > > Hey, > > > > > > I was wondering how this is going. Are you guys still stuck, > > waiting for Denis to help out? > > > > > > -hendrik > > > > > > > > >> On Mar 30, 2018, at 07:32, shashidhara.veerabhadraiah at oracle.com > > wrote: > > >> > > >> Sure. I did had a confusion to put for review though but did not > > know what to do and felt not to keep waiting. Thanks for the > > direction Sergey. > > >> > > >> Thanks and regards, > > >> Shashi > > >> > > >> > > >> On 29/03/18 7:45 PM, Sergey Bylokhov wrote: > > >>> Unfortunately we cannot accept the patch which were suggested > > in the description of the bug. Initially it was implemented in > > JetBrains JRE. We can accept it if someone from the JetBrains will > > contribute it. > > >>> > > >>> Maybe Denis who is author of the fix can help? > > >>> > > >>> On 28/03/2018 02:29, Shashidhara Veerabhadraiah wrote: > > >>>> Hi All, Please review an enhancement for the below bug: > > >>>> > > >>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8181910 > > >>>> > > >>>> Webrev: > > http://cr.openjdk.java.net/~sveerabhadra/8181910/webrev.00/ > > >>>> > > >>>> This utilizes the NSAppearance to set the appearance theme to > > dark or light. > > >>>> > > >>>> Thanks and regards, > > >>>> > > >>>> Shashi > > >>>> > > >>> > > >>> > > >> > > > > > > > > > -- > > Best regards, Sergey. > > > > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashidhara.veerabhadraiah at oracle.com Fri Apr 13 10:35:36 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Fri, 13 Apr 2018 03:35:36 -0700 (PDT) Subject: [11] JDK-8181910: [macos] Support dark title bars on macOS In-Reply-To: References: <9e2fcb3c-425e-6ad7-7778-5a297902df64@oracle.com> <81ed89d6-0d65-f2ca-d565-488466050634@oracle.com> <3a7be52c-a086-4c2f-a2f8-2f52bc654269@default> Message-ID: <6ef9599a-a2df-45f3-aac8-4389f8054651@default> Thank you Denis and Sergey for the review. ? -Shashi ? From: Denis Fokin [mailto:denis.fokin at gmail.com] Sent: Friday, April 13, 2018 3:58 PM To: Shashidhara Veerabhadraiah Cc: Sergey Bylokhov ; Hendrik Schreiber ; awt-dev at openjdk.java.net Subject: Re: [11] JDK-8181910: [macos] Support dark title bars on macOS ? Hi?Shashi, ? Thank you for the fix, it looks fine. ? Thank you, ? ?Denis. ? On Thu, Apr 12, 2018 at 7:30 AM Shashidhara Veerabhadraiah wrote: Thank you Sergey for the review. Denis, Please let me know if you have any comments on the changes. Thanks and regards, Shashi -----Original Message----- From: Sergey Bylokhov Sent: Thursday, April 12, 2018 3:36 AM To: Denis Fokin Cc: Hendrik Schreiber ; Shashidhara Veerabhadraiah ; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net Subject: Re: [11] JDK-8181910: [macos] Support dark title bars on macOS Thank you, the fix looks fine. On 11/04/2018 07:44, Denis Fokin wrote: > Hi Sergey, > > can I just approve any modifications and usage of the patch? I am > absolutely ok with pushing or improving the fix by?Shashidhara. > > __ > Thank you, >? ? ? Denis > > On Tue, Apr 3, 2018 at 10:50 PM Sergey Bylokhov > > wrote: > >? ? ?Yes, this fix can be contributed by someone from the JB. > >? ? ?On 03/04/2018 06:48, Hendrik Schreiber wrote: >? ? ? > Hey, >? ? ? > >? ? ? > I was wondering how this is going. Are you guys still stuck, >? ? ?waiting for Denis to help out? >? ? ? > >? ? ? > -hendrik >? ? ? > >? ? ? > >? ? ? >> On Mar 30, 2018, at 07:32, HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"shashidhara.veerabhadraiah at oracle.com >? ? ? wrote: >? ? ? >> >? ? ? >> Sure. I did had a confusion to put for review though but did not >? ? ?know what to do and felt not to keep waiting. Thanks for the >? ? ?direction Sergey. >? ? ? >> >? ? ? >> Thanks and regards, >? ? ? >> Shashi >? ? ? >> >? ? ? >> >? ? ? >> On 29/03/18 7:45 PM, Sergey Bylokhov wrote: >? ? ? >>> Unfortunately we cannot accept the patch which were suggested >? ? ?in the description of the bug. Initially it was implemented in >? ? ?JetBrains JRE. We can accept it if someone from the JetBrains will >? ? ?contribute it. >? ? ? >>> >? ? ? >>> Maybe Denis who is author of the fix can help? >? ? ? >>> >? ? ? >>> On 28/03/2018 02:29, Shashidhara Veerabhadraiah wrote: >? ? ? >>>> Hi All, Please review an enhancement for the below bug: >? ? ? >>>> >? ? ? >>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8181910 >? ? ? >>>> >? ? ? >>>> Webrev: >? ? ?http://cr.openjdk.java.net/~sveerabhadra/8181910/webrev.00/ >? ? ? >>>> >? ? ? >>>> This utilizes the NSAppearance to set the appearance theme to >? ? ?dark or light. >? ? ? >>>> >? ? ? >>>> Thanks and regards, >? ? ? >>>> >? ? ? >>>> Shashi >? ? ? >>>> >? ? ? >>> >? ? ? >>> >? ? ? >> >? ? ? > > > >? ? ?-- >? ? ?Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Apr 13 13:28:53 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Apr 2018 15:28:53 +0200 Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless Message-ID: Hi, can I please have a review for this tiny AIX cleanup: http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ https://bugs.openjdk.java.net/browse/JDK-8201524 This is a follow up change of JDK-8196516 which discovered that on AIX libfontmanager is always linked against libawt_headless at build time. If we are running in a headfull environment, libfontmanager will dynamically load libawt_xawt which is not good because libawt_headless and libawt_xawt define some common symbols. If we're running in a headless environment, libawt_headless may be loaded a second time (at least on Linux/Solaris) which isn't good either. Both of these scenarios haven't caused any problems on AIX yet, but I think it's good to cleanup the AIX implementation as well and don't link libfontmanager against libawt_headless anymore. In order to achieve this, we have to allow unresolved symbols during the linking of libfontmanager. This can be easily achieved by adding the additions linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine for AIX because options which come later on the command line take precedence over earlier ones. Thank you and best regards, Volker From christoph.langer at sap.com Fri Apr 13 14:28:16 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 13 Apr 2018 14:28:16 +0000 Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: References: Message-ID: <3e0b6c7ffd77407fae20597cc28865c8@sap.com> Hi Volker, looks good. Best regards Christoph > -----Original Message----- > From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf Of > Volker Simonis > Sent: Freitag, 13. April 2018 15:29 > To: awt-dev ; build-dev dev at openjdk.java.net> > Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager > against libawt_headless > > Hi, > > can I please have a review for this tiny AIX cleanup: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ > https://bugs.openjdk.java.net/browse/JDK-8201524 > > This is a follow up change of JDK-8196516 which discovered that on AIX > libfontmanager is always linked against libawt_headless at build time. > If we are running in a headfull environment, libfontmanager will > dynamically load libawt_xawt which is not good because libawt_headless > and libawt_xawt define some common symbols. If we're running in a > headless environment, libawt_headless may be loaded a second time (at > least on Linux/Solaris) which isn't good either. > > Both of these scenarios haven't caused any problems on AIX yet, but I > think it's good to cleanup the AIX implementation as well and don't > link libfontmanager against libawt_headless anymore. In order to > achieve this, we have to allow unresolved symbols during the linking > of libfontmanager. This can be easily achieved by adding the additions > linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine > for AIX because options which come later on the command line take > precedence > over earlier ones. > > Thank you and best regards, > Volker From erik.joelsson at oracle.com Fri Apr 13 16:00:39 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 13 Apr 2018 09:00:39 -0700 Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: References: Message-ID: Hello Volker, The change looks good, but now that we no longer link against libawt_headless, we should also remove the make dependency a few lines down. (Should have been done already for Solaris.) /Erik On 2018-04-13 06:28, Volker Simonis wrote: > Hi, > > can I please have a review for this tiny AIX cleanup: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ > https://bugs.openjdk.java.net/browse/JDK-8201524 > > This is a follow up change of JDK-8196516 which discovered that on AIX > libfontmanager is always linked against libawt_headless at build time. > If we are running in a headfull environment, libfontmanager will > dynamically load libawt_xawt which is not good because libawt_headless > and libawt_xawt define some common symbols. If we're running in a > headless environment, libawt_headless may be loaded a second time (at > least on Linux/Solaris) which isn't good either. > > Both of these scenarios haven't caused any problems on AIX yet, but I > think it's good to cleanup the AIX implementation as well and don't > link libfontmanager against libawt_headless anymore. In order to > achieve this, we have to allow unresolved symbols during the linking > of libfontmanager. This can be easily achieved by adding the additions > linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine > for AIX because options which come later on the command line take > precedence > over earlier ones. > > Thank you and best regards, > Volker From volker.simonis at gmail.com Fri Apr 13 16:22:18 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Apr 2018 18:22:18 +0200 Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: References: Message-ID: Hi Erik, thanks for looking at the patch and good catch! You're right that the dependency can now be removed. Here's the new webrev: http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 Regards, Volker On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson wrote: > Hello Volker, > > The change looks good, but now that we no longer link against > libawt_headless, we should also remove the make dependency a few lines down. > (Should have been done already for Solaris.) > > /Erik > > > > On 2018-04-13 06:28, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for this tiny AIX cleanup: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ >> https://bugs.openjdk.java.net/browse/JDK-8201524 >> >> This is a follow up change of JDK-8196516 which discovered that on AIX >> libfontmanager is always linked against libawt_headless at build time. >> If we are running in a headfull environment, libfontmanager will >> dynamically load libawt_xawt which is not good because libawt_headless >> and libawt_xawt define some common symbols. If we're running in a >> headless environment, libawt_headless may be loaded a second time (at >> least on Linux/Solaris) which isn't good either. >> >> Both of these scenarios haven't caused any problems on AIX yet, but I >> think it's good to cleanup the AIX implementation as well and don't >> link libfontmanager against libawt_headless anymore. In order to >> achieve this, we have to allow unresolved symbols during the linking >> of libfontmanager. This can be easily achieved by adding the additions >> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine >> for AIX because options which come later on the command line take >> precedence >> over earlier ones. >> >> Thank you and best regards, >> Volker > > From philip.race at oracle.com Fri Apr 13 17:20:59 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 13 Apr 2018 10:20:59 -0700 Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: References: Message-ID: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> I suppose this potentially helps the concurrency of the build ? I can't think of why this would be a problem now there is no compile-time linking involved and it seems Linux was already fine without this, but a jdk-submit would be prudent .. -phil. On 04/13/2018 09:22 AM, Volker Simonis wrote: > Hi Erik, > > thanks for looking at the patch and good catch! You're right that the > dependency can now be removed. Here's the new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 > > Regards, > Volker > > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson wrote: >> Hello Volker, >> >> The change looks good, but now that we no longer link against >> libawt_headless, we should also remove the make dependency a few lines down. >> (Should have been done already for Solaris.) >> >> /Erik >> >> >> >> On 2018-04-13 06:28, Volker Simonis wrote: >>> Hi, >>> >>> can I please have a review for this tiny AIX cleanup: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ >>> https://bugs.openjdk.java.net/browse/JDK-8201524 >>> >>> This is a follow up change of JDK-8196516 which discovered that on AIX >>> libfontmanager is always linked against libawt_headless at build time. >>> If we are running in a headfull environment, libfontmanager will >>> dynamically load libawt_xawt which is not good because libawt_headless >>> and libawt_xawt define some common symbols. If we're running in a >>> headless environment, libawt_headless may be loaded a second time (at >>> least on Linux/Solaris) which isn't good either. >>> >>> Both of these scenarios haven't caused any problems on AIX yet, but I >>> think it's good to cleanup the AIX implementation as well and don't >>> link libfontmanager against libawt_headless anymore. In order to >>> achieve this, we have to allow unresolved symbols during the linking >>> of libfontmanager. This can be easily achieved by adding the additions >>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine >>> for AIX because options which come later on the command line take >>> precedence >>> over earlier ones. >>> >>> Thank you and best regards, >>> Volker >> From erik.joelsson at oracle.com Fri Apr 13 18:28:36 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 13 Apr 2018 11:28:36 -0700 Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: References: Message-ID: <19047fbc-0d30-cc3d-e289-6a42a419a49e@oracle.com> Looks good, thanks! /Erik On 2018-04-13 09:22, Volker Simonis wrote: > Hi Erik, > > thanks for looking at the patch and good catch! You're right that the > dependency can now be removed. Here's the new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 > > Regards, > Volker > > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson wrote: >> Hello Volker, >> >> The change looks good, but now that we no longer link against >> libawt_headless, we should also remove the make dependency a few lines down. >> (Should have been done already for Solaris.) >> >> /Erik >> >> >> >> On 2018-04-13 06:28, Volker Simonis wrote: >>> Hi, >>> >>> can I please have a review for this tiny AIX cleanup: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ >>> https://bugs.openjdk.java.net/browse/JDK-8201524 >>> >>> This is a follow up change of JDK-8196516 which discovered that on AIX >>> libfontmanager is always linked against libawt_headless at build time. >>> If we are running in a headfull environment, libfontmanager will >>> dynamically load libawt_xawt which is not good because libawt_headless >>> and libawt_xawt define some common symbols. If we're running in a >>> headless environment, libawt_headless may be loaded a second time (at >>> least on Linux/Solaris) which isn't good either. >>> >>> Both of these scenarios haven't caused any problems on AIX yet, but I >>> think it's good to cleanup the AIX implementation as well and don't >>> link libfontmanager against libawt_headless anymore. In order to >>> achieve this, we have to allow unresolved symbols during the linking >>> of libfontmanager. This can be easily achieved by adding the additions >>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine >>> for AIX because options which come later on the command line take >>> precedence >>> over earlier ones. >>> >>> Thank you and best regards, >>> Volker >> From erik.joelsson at oracle.com Fri Apr 13 18:31:15 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 13 Apr 2018 11:31:15 -0700 Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> References: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> Message-ID: <77be34a6-352e-7ded-7be3-a6e0b02d9a74@oracle.com> Yes, we don't want unneeded dependencies declared as it both potentially slows down the build (though this removal will not have any measurable impact) as well as confuses humans trying to make sense of the makefiles. This removal should be fine as we don't link to libawt_xawt on any platform anymore. Linking is the only reason we have those dependencies. /Erik On 2018-04-13 10:20, Phil Race wrote: > > I suppose this potentially helps the concurrency of the build ? > I can't think of why this would be a problem now there is no > compile-time linking > involved and it seems Linux was already fine without this, > but a jdk-submit would be prudent .. > > -phil. > > On 04/13/2018 09:22 AM, Volker Simonis wrote: >> Hi Erik, >> >> thanks for looking at the patch and good catch! You're right that the >> dependency can now be removed. Here's the new webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 >> >> Regards, >> Volker >> >> On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson >> wrote: >>> Hello Volker, >>> >>> The change looks good, but now that we no longer link against >>> libawt_headless, we should also remove the make dependency a few >>> lines down. >>> (Should have been done already for Solaris.) >>> >>> /Erik >>> >>> >>> >>> On 2018-04-13 06:28, Volker Simonis wrote: >>>> Hi, >>>> >>>> can I please have a review for this tiny AIX cleanup: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ >>>> https://bugs.openjdk.java.net/browse/JDK-8201524 >>>> >>>> This is a follow up change of JDK-8196516 which discovered that on AIX >>>> libfontmanager is always linked against libawt_headless at build time. >>>> If we are running in a headfull environment, libfontmanager will >>>> dynamically load libawt_xawt which is not good because libawt_headless >>>> and libawt_xawt define some common symbols. If we're running in a >>>> headless environment, libawt_headless may be loaded a second time (at >>>> least on Linux/Solaris) which isn't good either. >>>> >>>> Both of these scenarios haven't caused any problems on AIX yet, but I >>>> think it's good to cleanup the AIX implementation as well and don't >>>> link libfontmanager against libawt_headless anymore. In order to >>>> achieve this, we have to allow unresolved symbols during the linking >>>> of libfontmanager. This can be easily achieved by adding the additions >>>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine >>>> for AIX because options which come later on the command line take >>>> precedence >>>> over earlier ones. >>>> >>>> Thank you and best regards, >>>> Volker >>> > From volker.simonis at gmail.com Fri Apr 13 19:44:36 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Apr 2018 19:44:36 +0000 Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> References: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> Message-ID: Phil Race schrieb am Fr. 13. Apr. 2018 um 19:21: > > I suppose this potentially helps the concurrency of the build ? > I can't think of why this would be a problem now there is no > compile-time linking > involved and it seems Linux was already fine without this, > but a jdk-submit would be prudent .. > I did start Solaris and AIX builds before I left the office. I can certainly also submit a job to JDK-submit, but at least hs-submit wasn?t working at all (i.e. didn?t return any results). > -phil. > > On 04/13/2018 09:22 AM, Volker Simonis wrote: > > Hi Erik, > > > > thanks for looking at the patch and good catch! You're right that the > > dependency can now be removed. Here's the new webrev: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 > > > > Regards, > > Volker > > > > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson > wrote: > >> Hello Volker, > >> > >> The change looks good, but now that we no longer link against > >> libawt_headless, we should also remove the make dependency a few lines > down. > >> (Should have been done already for Solaris.) > >> > >> /Erik > >> > >> > >> > >> On 2018-04-13 06:28, Volker Simonis wrote: > >>> Hi, > >>> > >>> can I please have a review for this tiny AIX cleanup: > >>> > >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ > >>> https://bugs.openjdk.java.net/browse/JDK-8201524 > >>> > >>> This is a follow up change of JDK-8196516 which discovered that on AIX > >>> libfontmanager is always linked against libawt_headless at build time. > >>> If we are running in a headfull environment, libfontmanager will > >>> dynamically load libawt_xawt which is not good because libawt_headless > >>> and libawt_xawt define some common symbols. If we're running in a > >>> headless environment, libawt_headless may be loaded a second time (at > >>> least on Linux/Solaris) which isn't good either. > >>> > >>> Both of these scenarios haven't caused any problems on AIX yet, but I > >>> think it's good to cleanup the AIX implementation as well and don't > >>> link libfontmanager against libawt_headless anymore. In order to > >>> achieve this, we have to allow unresolved symbols during the linking > >>> of libfontmanager. This can be easily achieved by adding the additions > >>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine > >>> for AIX because options which come later on the command line take > >>> precedence > >>> over earlier ones. > >>> > >>> Thank you and best regards, > >>> Volker > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri Apr 13 19:53:59 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 13 Apr 2018 12:53:59 -0700 Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: References: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> Message-ID: On 2018-04-13 12:44, Volker Simonis wrote: > > Phil Race > > schrieb am Fr. 13. Apr. 2018 um 19:21: > > > I suppose this potentially helps the concurrency of the build ? > I can't think of why this would be a problem now there is no > compile-time linking > involved and it seems Linux was already fine without this, > but a jdk-submit would be prudent .. > > > I did start Solaris and AIX builds before I left the office. I can > certainly also submit a job to JDK-submit, but at least hs-submit > wasn?t working at all (i.e. didn?t return any results). > hs-submit is disabled since the merge of jdk/hs to jdk/jdk. /Erik > > > -phil. > > On 04/13/2018 09:22 AM, Volker Simonis wrote: > > Hi Erik, > > > > thanks for looking at the patch and good catch! You're right > that the > > dependency can now be removed. Here's the new webrev: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 > > > > > Regards, > > Volker > > > > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson > > wrote: > >> Hello Volker, > >> > >> The change looks good, but now that we no longer link against > >> libawt_headless, we should also remove the make dependency a > few lines down. > >> (Should have been done already for Solaris.) > >> > >> /Erik > >> > >> > >> > >> On 2018-04-13 06:28, Volker Simonis wrote: > >>> Hi, > >>> > >>> can I please have a review for this tiny AIX cleanup: > >>> > >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ > > >>> https://bugs.openjdk.java.net/browse/JDK-8201524 > >>> > >>> This is a follow up change of JDK-8196516 which discovered > that on AIX > >>> libfontmanager is always linked against libawt_headless at > build time. > >>> If we are running in a headfull environment, libfontmanager will > >>> dynamically load libawt_xawt which is not good because > libawt_headless > >>> and libawt_xawt define some common symbols. If we're running in a > >>> headless environment, libawt_headless may be loaded a second > time (at > >>> least on Linux/Solaris) which isn't good either. > >>> > >>> Both of these scenarios haven't caused any problems on AIX > yet, but I > >>> think it's good to cleanup the AIX implementation as well and > don't > >>> link libfontmanager against libawt_headless anymore. In order to > >>> achieve this, we have to allow unresolved symbols during the > linking > >>> of libfontmanager. This can be easily achieved by adding the > additions > >>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This > works fine > >>> for AIX because options which come later on the command line take > >>> precedence > >>> over earlier ones. > >>> > >>> Thank you and best regards, > >>> Volker > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Apr 13 19:59:49 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 13 Apr 2018 12:59:49 -0700 Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: References: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> Message-ID: <2e82d272-3cda-9786-f5bf-14dd188fc2ec@oracle.com> On 04/13/2018 12:44 PM, Volker Simonis wrote: > > Phil Race > > schrieb am Fr. 13. Apr. 2018 um 19:21: > > > I suppose this potentially helps the concurrency of the build ? > I can't think of why this would be a problem now there is no > compile-time linking > involved and it seems Linux was already fine without this, > but a jdk-submit would be prudent .. > > > I did start Solaris and AIX builds before I left the office. That should be sufficient ... -phil. > I can certainly also submit a job to JDK-submit, but at least > hs-submit wasn?t working at all (i.e. didn?t return any results). > > > -phil. > > On 04/13/2018 09:22 AM, Volker Simonis wrote: > > Hi Erik, > > > > thanks for looking at the patch and good catch! You're right > that the > > dependency can now be removed. Here's the new webrev: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 > > > > > Regards, > > Volker > > > > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson > > wrote: > >> Hello Volker, > >> > >> The change looks good, but now that we no longer link against > >> libawt_headless, we should also remove the make dependency a > few lines down. > >> (Should have been done already for Solaris.) > >> > >> /Erik > >> > >> > >> > >> On 2018-04-13 06:28, Volker Simonis wrote: > >>> Hi, > >>> > >>> can I please have a review for this tiny AIX cleanup: > >>> > >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ > > >>> https://bugs.openjdk.java.net/browse/JDK-8201524 > >>> > >>> This is a follow up change of JDK-8196516 which discovered > that on AIX > >>> libfontmanager is always linked against libawt_headless at > build time. > >>> If we are running in a headfull environment, libfontmanager will > >>> dynamically load libawt_xawt which is not good because > libawt_headless > >>> and libawt_xawt define some common symbols. If we're running in a > >>> headless environment, libawt_headless may be loaded a second > time (at > >>> least on Linux/Solaris) which isn't good either. > >>> > >>> Both of these scenarios haven't caused any problems on AIX > yet, but I > >>> think it's good to cleanup the AIX implementation as well and > don't > >>> link libfontmanager against libawt_headless anymore. In order to > >>> achieve this, we have to allow unresolved symbols during the > linking > >>> of libfontmanager. This can be easily achieved by adding the > additions > >>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This > works fine > >>> for AIX because options which come later on the command line take > >>> precedence > >>> over earlier ones. > >>> > >>> Thank you and best regards, > >>> Volker > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.litvinov at oracle.com Mon Apr 16 12:03:50 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Mon, 16 Apr 2018 13:03:50 +0100 Subject: [11] Review request for 8199748: Touch keyboard is not shown, if text component gets focus from other text component Message-ID: Hello, Could you please review the following fix for the bug. Bug: https://bugs.openjdk.java.net/browse/JDK-8199748 Webrev: http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.00 In the fix for JDK-8166772 it was deliberately implemented that the touch keyboard is shown only on "MouseEvent.MOUSE_RELEASED" event and is hidden on "FocusEvent.FOCUS_LOST" event. The reason of the bug is the fact that, when the touch keyboard is already shown for one text component and a user touches another text component, then the following 2 events occur in the presented order: 1. "MouseEvent.MOUSE_RELEASED" event arrives. The touch keyboard is shown for the new text component. 2. "FocusEvent.FOCUS_LOST" event arrives for the previous text component. The touch keyboard shown for the new text component becomes hidden. The fix allows not to hide the touch keyboard during processing of "FocusEvent.FOCUS_LOST" event, if the touch keyboard has just been shown, as a result of processing of "MouseEvent.MOUSE_RELEASED" event, for the component which gets focus "FocusEvent.getOppositeComponent()". Thank you, Anton From magnus.ihse.bursie at oracle.com Mon Apr 16 12:26:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Apr 2018 14:26:52 +0200 Subject: [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 In-Reply-To: References: Message-ID: <2adbd191-0059-f70b-2691-833b49d6e5fd@oracle.com> Hi Alexey, Since this patch, I'm getting lots of warnings on Windows: c:/cygwin64/home/magnusi/hg/sandbox/open/src/java.base/windows/native/launcher/java.manifest : manifest authoring warning 81010002: Unrecognized Element "dpiAwareness" in namespace "http://schemas.microsoft.com/SMI/2016/WindowsSettings". Seems this element is not universally recognized. Does it even work as intended? Do you have any suggestion on how to address this issue? /Magnus On 2018-04-06 00:39, Alexey Ivanov wrote: > Hello, > > Could you please review the fix for jdk11? > > bug: https://bugs.openjdk.java.net/browse/JDK-8199627 > webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/ > > > Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1] > > Java already supports "Per-Monitor v1" mode. This change extends High > DPI support in Java: in addition to element [2], a new > element [3] is added to Java launcher manifest. The > element is recognized by Windows 10 v1607 and above, > PerMonitorV2 value is supported by Windows 10 v1703 and above. > > The most notable change for Java applications is that window title bar > is scaled correctly when application window moves from one monitor to > another or the scaling changes. > > > When building, manifest tool generates warning for unknown > element in manifest. It is because an older Windows SDK > is used to build JDK which does not know about an element that was > added later. The build succeeds despite the warning. > > > Thank you in advance. > > Regards, > Alexey > > [1] > https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ > > > [2] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware > > > [3] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness > > From alexey.ivanov at oracle.com Mon Apr 16 12:49:19 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 16 Apr 2018 13:49:19 +0100 Subject: [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI awareness for Windows 10 v1703 In-Reply-To: <2adbd191-0059-f70b-2691-833b49d6e5fd@oracle.com> References: <2adbd191-0059-f70b-2691-833b49d6e5fd@oracle.com> Message-ID: Hi Magnus, I haven't found a way to suppress this warning. I tried. There's no way to suppress warnings from mt.exe [1] unfortunately. We're using Visual Studio 2013 to build JDK, the element was added in 2016. Newer versions of Windows SDK should recognise the element. Yes, it works as intended. It's recognised by Windows 10 v1703 and later and changes High DPI mode. Other versions of Windows are not affected. I should've included build-dev into the review process as it affects build system. Can the output of mt.exe be redirected? If it's successful, then its output gets ignored. Regards, Alexey [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa375649(v=vs.85).aspx On 16/04/2018 13:26, Magnus Ihse Bursie wrote: > Hi Alexey, > > Since this patch, I'm getting lots of warnings on Windows: > > c:/cygwin64/home/magnusi/hg/sandbox/open/src/java.base/windows/native/launcher/java.manifest > : manifest authoring warning 81010002: Unrecognized Element > "dpiAwareness" in namespace > "http://schemas.microsoft.com/SMI/2016/WindowsSettings". > > Seems this element is not universally recognized. Does it even work as > intended? > > Do you have any suggestion on how to address this issue? > > /Magnus > > On 2018-04-06 00:39, Alexey Ivanov wrote: >> Hello, >> >> Could you please review the fix for jdk11? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8199627 >> webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/ >> >> >> Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1] >> >> >> >> >> When building, manifest tool generates warning for unknown >> element in manifest. It is because an older Windows >> SDK is used to build JDK which does not know about an element that >> was added later. The build succeeds despite the warning. >> >> >> Thank you in advance. >> >> Regards, >> Alexey >> >> [1] >> https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ >> [2] >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware >> [3] >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness > From takiguc at linux.vnet.ibm.com Mon Apr 16 17:41:51 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 17 Apr 2018 02:41:51 +0900 Subject: Proposal:AIX's IME support In-Reply-To: <428f37b3-0a64-b727-2426-9c96fd8155a9@oracle.com> References: <2ed52f9dc4e9487c7b3131b5af3666d9@linux.vnet.ibm.com> <428f37b3-0a64-b727-2426-9c96fd8155a9@oracle.com> Message-ID: <8062d9b71e62b0fc92ae505be9e08e85@linux.vnet.ibm.com> Hello. Sorry I'm late. Christoph Langer helped me to put webrev file into cr.openjdk.java.net. See, http://cr.openjdk.java.net/~clanger/webrevs/8201429.0/ Actually, he found *.patch files had unexpected entries, I fixed the issue. It seemed that webrev tool could not handle "hg copy" action. It was reported by, http://mail.openjdk.java.net/pipermail/webrev-dev/2018-April/000145.html So above webrev file should be fine. Please let me know if you have any question and suggestion about webrev file for AIX's IME support. Thanks, Ichiroh Takiguchi On 2018-04-10 07:39, Sergey Bylokhov wrote: > Hi, Ichiroh. > Your contribution is welcome. Can you send the change for review as a > webrev on cr.openjdk.java.net? > > On 09/04/2018 02:09, Ichiroh Takiguchi wrote: >> Hello, >> IBM would like to propose another Input Method Framework (IMF) >> implementation against IBM AIX platform. >> Same IMF implementation was used by IBM Java8 for AIX. >> IBM would like to contribute this IMF implementation to OpenJDK >> project. >> >> AIX's Input Method Editor (IME) working behavior is not same as >> Linux's and Solaris' one. >> On OpenJDK JDK9 for AIX, users cannot input any East Asian character >> with their locale by this IME. >> We think this situation is critical. >> Put modified files under src/java.desktop/aix/* directories in order >> not to affect the other unix platform. >> >> I'd like contribute following 4 files: >> M make/lib/Awt2dLibraries.gmk >> A src/java.desktop/aix/classes/sun/awt/X11InputMethod.java >> A src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c >> A src/java.desktop/aix/native/libawt_xawt/xawt/XlibWrapper.c >> >> We need to apply too many changes including JNI, so we copied >> following 3 files from unix directory to aix directory: >> * src/java.desktop/unix/classes/sun/awt/X11InputMethod.java >> * src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >> * src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c >> Then, we modified them. >> >> I'd appreciate any feedback please, and how I would go about obtaining >> a sponsor and contributor? >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> From philip.race at oracle.com Mon Apr 16 19:01:44 2018 From: philip.race at oracle.com (Philip Race) Date: Mon, 16 Apr 2018 12:01:44 -0700 Subject: [11] Review Request: 8199932 Missing copyright header in AWT source code In-Reply-To: <668b7c74-bdd9-b26a-1427-6d833f032be9@oracle.com> References: <668b7c74-bdd9-b26a-1427-6d833f032be9@oracle.com> Message-ID: <5AD4F318.90100@oracle.com> +1 -phil. On 4/6/18, 5:25 PM, Sergey Bylokhov wrote: > Hello. > Please review small cleanup for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199932 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8199932/webrev.00 > > A few places were updated to have correct specification(gpl+cp). > From philip.race at oracle.com Mon Apr 16 19:04:27 2018 From: philip.race at oracle.com (Philip Race) Date: Mon, 16 Apr 2018 12:04:27 -0700 Subject: [11] Review Request: 8187392 Deprecated methods in the peers can be removed In-Reply-To: References: Message-ID: <5AD4F3BB.7090105@oracle.com> +1 -phil. On 4/3/18, 11:43 PM, Sergey Bylokhov wrote: > Hello. > Please review fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187392 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8187392/webrev.05 > > In jdk1.0 era the "java.awt.peer.ComponentPeer" interface had a few > methods which were replaced and removed in jdk1.1, but some of > implementations of these methods were not removed(just deprecated). > This change will remove them. > From philip.race at oracle.com Mon Apr 16 19:09:36 2018 From: philip.race at oracle.com (Philip Race) Date: Mon, 16 Apr 2018 12:09:36 -0700 Subject: [11] Review Request: 8200146 Remove the appletviewer launcher In-Reply-To: <419d6585-fa7f-f14a-bac8-3129ceb53c8b@oracle.com> References: <419d6585-fa7f-f14a-bac8-3129ceb53c8b@oracle.com> Message-ID: <5AD4F4F0.3010502@oracle.com> +1 -phil. On 3/30/18, 3:52 PM, Sergey Bylokhov wrote: > Hello. > Please review fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200146 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8200146/webrev.00 > CSR: https://bugs.openjdk.java.net/browse/JDK-8200549 > > Fix description: > - The appletviewer launcher was removed from jdk/bin > - The man pages were removed > - Two tests which used appletviewer launcher directly were removed > > Note that the appletviewer was deprecated in in jdk9: > https://bugs.openjdk.java.net/browse/JDK-8074165 > From Sergey.Bylokhov at oracle.com Mon Apr 16 23:48:26 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 16 Apr 2018 16:48:26 -0700 Subject: [11] Review request for 8199748: Touch keyboard is not shown, if text component gets focus from other text component In-Reply-To: References: Message-ID: <2e0c6d5f-2e4d-5f8c-6737-729301e7f44c@oracle.com> Hi, Anton. Maybe this was discussed before, but can you please clarify why we did not show the keyborad on focus_gain? BTW looks like the WTookit.compOnxxx should be a weak references. On 16/04/2018 05:03, Anton Litvinov wrote: > Hello, > > Could you please review the following fix for the bug. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199748 > Webrev: http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.00 > > In the fix for JDK-8166772 it was deliberately implemented that the > touch keyboard is shown only on "MouseEvent.MOUSE_RELEASED" event and is > hidden on "FocusEvent.FOCUS_LOST" event. > > The reason of the bug is the fact that, when the touch keyboard is > already shown for one text component and a user touches another text > component, then the following 2 events occur in the presented order: > 1. "MouseEvent.MOUSE_RELEASED" event arrives. The touch keyboard is > shown for the new text component. > 2. "FocusEvent.FOCUS_LOST" event arrives for the previous text > component. The touch keyboard shown for the new text component becomes > hidden. > > The fix allows not to hide the touch keyboard during processing of > "FocusEvent.FOCUS_LOST" event, if the touch keyboard has just been > shown, as a result of processing of "MouseEvent.MOUSE_RELEASED" event, > for the component which gets focus "FocusEvent.getOppositeComponent()". > > Thank you, > Anton -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Apr 17 01:11:41 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 16 Apr 2018 18:11:41 -0700 Subject: [11] Review Request: 8201626 Typo in MakeWindowAlwaysOnTop test Message-ID: Hello. Please review the fix for jdk11. The small typo was fixed. Bug: https://bugs.openjdk.java.net/browse/JDK-8201626 Fix is inline below: diff test/jdk/java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java @key headful - @bug 6829546, 8197808 + @bug 6829546 8197808 @summary tests that an always-on-top modal dialog doesn't make any windows always-on-top -- Best regards, Sergey. From javalists at cbfiddle.com Tue Apr 17 01:25:57 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 16 Apr 2018 18:25:57 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors In-Reply-To: <35F57A44-F3B1-484B-9A88-66849FFA9E47@cbfiddle.com> References: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> <22D883A4-B362-411D-82F7-76A418487ADE@cbfiddle.com> <35F57A44-F3B1-484B-9A88-66849FFA9E47@cbfiddle.com> Message-ID: Hi Sergey, There is one other factor needed to explain the zombie color panel: The program is leaving behind stale window data, specifically, descriptions of windows that were closed prior to the termination of the program. The cause of this stale data is that AWT does not terminate the NSApplication that it created. When the NSApplication is terminated, it deletes the window data if there are no open windows. The failure to terminate the NSApplication has not been a problem in general because AWT windows are not capable of being restored in a new process, but NSColorPanel is. I have now seen this problem in my own (bundled) application, which allows the user to bring up a color panel. The only observable flaw for most AWT applications is the saved state directories left behind. In the future, however, AWT windows could be given the ability to be recreated in a new process. That, and the possibility that NSApplication might do more cleanup in future macOS releases, would argue for fixing this problem. The solution is to invoke [NSApp terminate], but that is tricky because it also terminates the process (it does not return). My recommendation is to put this test on the problem list until the NSApplication problem is solved. Regards, Alan > On Apr 10, 2018, at 11:39 AM, Alan Snyder wrote: > > Hi Sergey, > > I can use System Preferences instead of Finder to avoid problems with pre-existing windows and utility panels covering the test frames. > > I have also experienced the color panel reappearing in applications run using the java command. > > I notice there is a directory ~/Library/Saved Application State/net.java.openjdk/cmd.savedState, which contains information about windows, including the color panel and the Java frames that were closed. I do not know how to prevent the color panel from reopening, other than by disabling this feature for the java command. > > See: https://apple.stackexchange.com/questions/177428/how-to-prevent-one-app-from-saving-restoring-any-saved-state > > It seems to me that saving information for the java command is a mistake, as it is an application launcher, not a single application. Perhaps the JDK installer should disable this feature. > > Alan > > > > >> On Apr 9, 2018, at 4:06 PM, Sergey Bylokhov > wrote: >> >> Hi, Alan. >> I just found a few side effects in the test. >> - All other tests(actually all java applications) which are executed after the new test will show colorPanel(until it will not be closed manually). >> - If the Finder will be opened in full screen(or in the location where the test will show the test windows) then the test will fail. Maybe it is better to use some other application to deactivate the test? Can we implement it using other java application?(you can run the same TestMainKeyWindow.main() and pass some flag to it) >> >> >> On 05/04/2018 16:15, Alan Snyder wrote: >>> Thank you for your comments. Here is the updated webrev: >>> http://cr.openjdk.java.net/~serb/alans/8194327/webrev.01/ >>> Alan >>>> On Apr 4, 2018, at 9:34 AM, Sergey Bylokhov >> wrote: >>>> >>>> Hi, Alan. >>>> A few comments about the test: >>>> - It is a mac specific and JtregNativeJdk should compile it on mac only >>>> - It should close all windows at the end, currently it leaves Finder opened. >>>> - it tries to use NSWindowStyleMask/NSWindowStyleMaskTitled which are available in >10.12. We only plan to move to 10.9 soon. So the test should skip it or use NSInteger/NSTitledWindowMask for macOS < MAC_OS_X_VERSION_10_12. >>>> - It looks like other tests in JtregNativeJdk.gmk use libtest+Some useful name, I suggest to use the same instead of bugid(same for the test name "Test.java"). >>>> BUILD_JDK_JTREG_LIBRARIES_LIBS_libtest819432 >>>> >>>> On 02/04/2018 19:35, Alan Snyder wrote: >>>>> Please review the following change to the macOS AWT. >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194327 >>>>> Webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.00/ >>>>> The goal of this change is to allow a Java desktop application on macOS to properly coexist with a native utility panel, such as the native color chooser. >>>>> The native color chooser is an example of a window that can become the key (focused) window but cannot become the main window. >>>>> If the previously active window is a Java frame, it should resign key window status (lose focus), but retain the main window status. >>>>> A window that is main but not key does not own the keyboard focus, but it appears active, and if it is using the screen menu bar, >>>>> it may be invoked to process a menu item action (if the menu item is not already handled by the key window). >>>>> The current macOS AWT does not support this combination of window states. A Java window is either key and main, or neither. >>>>> When the color chooser becomes key (obtains focus), the Java frame resigns both key and main status. >>>>> This change allows the key window status to be resigned while retaining the main window status, with the appropriate behavior. >>>>> Note that with this change, it remains impossible to implement a Java window that behaves like the native color chooser (i.e., can become key but not main). >>>>> That would require a much bigger change. >>>>> Alan >>>> >>>> >>>> -- >>>> Best regards, Sergey. >> >> >> -- >> Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Tue Apr 17 03:55:42 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 17 Apr 2018 03:55:42 +0000 (UTC) Subject: [11] Review Request: 8201626 Typo in MakeWindowAlwaysOnTop test In-Reply-To: References: Message-ID: <2bab4d4e-3a40-4714-901a-55e306bff95e@default> +1 -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, April 17, 2018 6:42 AM To: awt-dev at openjdk.java.net; Krishna Addepalli Subject: [11] Review Request: 8201626 Typo in MakeWindowAlwaysOnTop test Hello. Please review the fix for jdk11. The small typo was fixed. Bug: https://bugs.openjdk.java.net/browse/JDK-8201626 Fix is inline below: diff test/jdk/java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java @key headful - @bug 6829546, 8197808 + @bug 6829546 8197808 @summary tests that an always-on-top modal dialog doesn't make any windows always-on-top -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Tue Apr 17 14:00:34 2018 From: shashidhara.veerabhadraiah at oracle.com (shashidhara.veerabhadraiah at oracle.com) Date: Tue, 17 Apr 2018 19:30:34 +0530 Subject: [11] JDK-8201598: Fix for 8181910: Support dark title bars on macOS broke the MacOS build Message-ID: <0de0191e-c0d2-03bc-a88d-856f1e14dfa2@oracle.com> Hi All, Please review a fix for the below bug: Bug: https://bugs.openjdk.java.net/browse/JDK-8201598 Webrev: http://cr.openjdk.java.net/~sveerabhadra/8201598/webrev.00/ There are some of the constants(appkit constants) that are defined in 10.10 is used in the fix for JDK-8181910 without any compiler specific flag(like __MAC_10_10) as they are not available below 10.10 and since there is no available machines with Mac 10.9 for testing purpose, I would like undo the changeset introduced under JDK-8181910 and fix the problem later for the problem of having dark title bars(JDK-8181910) for the mac windows under a separate bug. Thanks and regards, Shashi From philip.race at oracle.com Tue Apr 17 15:27:24 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 17 Apr 2018 08:27:24 -0700 Subject: [11] JDK-8201598: Fix for 8181910: Support dark title bars on macOS broke the MacOS build In-Reply-To: <0de0191e-c0d2-03bc-a88d-856f1e14dfa2@oracle.com> References: <0de0191e-c0d2-03bc-a88d-856f1e14dfa2@oracle.com> Message-ID: +1 -phil. On 04/17/2018 07:00 AM, shashidhara.veerabhadraiah at oracle.com wrote: > Hi All, Please review a fix for the below bug: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201598 > > Webrev: http://cr.openjdk.java.net/~sveerabhadra/8201598/webrev.00/ > > There are some of the constants(appkit constants) that are defined in > 10.10 is used in the fix for JDK-8181910 without any compiler specific > flag(like __MAC_10_10) as they are not available below 10.10 and since > there is no available machines with Mac 10.9 for testing purpose, I > would like undo the changeset introduced under JDK-8181910 and fix the > problem later for the problem of having dark title bars(JDK-8181910) > for the mac windows under a separate bug. > > Thanks and regards, > > Shashi > From alexey.ivanov at oracle.com Tue Apr 17 16:24:59 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 17 Apr 2018 17:24:59 +0100 Subject: [11] Review request for 8199748: Touch keyboard is not shown, if text component gets focus from other text component In-Reply-To: References: Message-ID: <019c5cd2-367d-6c26-aa88-69cb5c68c217@oracle.com> Hi Anton, Shouldn't touch keyboard remain visible if Tab key on the touch keyboard itself is pressed? Provided the next focusable component is a text component, of course. Consider the following scenario: start Notepad and open Replace dialog. Touch "Find what" field: the touch keyboard appears. Press Tab on the touch keyboard: the focus moves to "Replace with" field and touch keyboard stays visible. Regards, Alexey On 16/04/2018 13:03, Anton Litvinov wrote: > Hello, > > Could you please review the following fix for the bug. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8199748 > Webrev: http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.00 > > In the fix for JDK-8166772 it was deliberately implemented that the > touch keyboard is shown only on "MouseEvent.MOUSE_RELEASED" event and > is hidden on "FocusEvent.FOCUS_LOST" event. > > The reason of the bug is the fact that, when the touch keyboard is > already shown for one text component and a user touches another text > component, then the following 2 events occur in the presented order: > 1. "MouseEvent.MOUSE_RELEASED" event arrives. The touch keyboard is > shown for the new text component. > 2. "FocusEvent.FOCUS_LOST" event arrives for the previous text > component. The touch keyboard shown for the new text component becomes > hidden. > > The fix allows not to hide the touch keyboard during processing of > "FocusEvent.FOCUS_LOST" event, if the touch keyboard has just been > shown, as a result of processing of "MouseEvent.MOUSE_RELEASED" event, > for the component which gets focus "FocusEvent.getOppositeComponent()". > > Thank you, > Anton From Sergey.Bylokhov at oracle.com Tue Apr 17 21:21:41 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Apr 2018 14:21:41 -0700 Subject: [11] JDK-8201598: Fix for 8181910: Support dark title bars on macOS broke the MacOS build In-Reply-To: References: <0de0191e-c0d2-03bc-a88d-856f1e14dfa2@oracle.com> Message-ID: +1 On 17/04/2018 08:27, Phil Race wrote: > +1 > > -phil. > > On 04/17/2018 07:00 AM, shashidhara.veerabhadraiah at oracle.com wrote: >> Hi All, Please review a fix for the below bug: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8201598 >> >> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8201598/webrev.00/ >> >> There are some of the constants(appkit constants) that are defined in >> 10.10 is used in the fix for JDK-8181910 without any compiler specific >> flag(like __MAC_10_10) as they are not available below 10.10 and since >> there is no available machines with Mac 10.9 for testing purpose, I >> would like undo the changeset introduced under JDK-8181910 and fix the >> problem later for the problem of having dark title bars(JDK-8181910) >> for the mac windows under a separate bug. >> >> Thanks and regards, >> >> Shashi >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Apr 18 01:36:16 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Apr 2018 18:36:16 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors In-Reply-To: References: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> <22D883A4-B362-411D-82F7-76A418487ADE@cbfiddle.com> <35F57A44-F3B1-484B-9A88-66849FFA9E47@cbfiddle.com> Message-ID: <60f03131-a79d-ed9a-d86d-3ea4be8184c2@oracle.com> On 16/04/2018 18:25, Alan Snyder wrote: > The failure to terminate the NSApplication has not been a problem in > general because AWT windows are not capable of being restored in a new > process, but NSColorPanel is. I have now seen this problem in my own > (bundled) application, which allows the user to bring up a color panel. I suggest you to create a separate CR for this bug for tracking. > The only observable flaw for most AWT applications is the saved state > directories left behind. In the future, however, AWT windows could be > given the ability to be recreated in a new process. That, and the > possibility that NSApplication might do more cleanup in future macOS > releases, would argue for fixing this problem. It is strange that it is visible only in case of color_panel, maybe it is possible to simplify the testcase and replace color_panel by some other NSWIndow? > > My recommendation is to put this test on the problem list until the > NSApplication problem is solved. > > Regards, > > ? Alan > > > > > >> On Apr 10, 2018, at 11:39 AM, Alan Snyder > > wrote: >> >> Hi Sergey, >> >> I can use System Preferences instead of Finder to avoid problems with >> pre-existing windows and utility panels covering the test frames. >> >> I have also experienced the color panel reappearing in applications >> run using the java command. >> >> I notice there is a directory ~/Library/Saved Application >> State/net.java.openjdk/cmd.savedState, which contains information >> about windows, including the color panel and the Java frames that were >> closed. I do not know how to prevent the color panel from reopening, >> other than by disabling this feature for the java command. >> >> See: >> https://apple.stackexchange.com/questions/177428/how-to-prevent-one-app-from-saving-restoring-any-saved-state >> >> It seems to me that saving information for the java command is a >> mistake, as it is an application launcher, not a single application. >> Perhaps the JDK installer should disable this feature. >> >> ? Alan >> >> >> >> >>> On Apr 9, 2018, at 4:06 PM, Sergey Bylokhov >>> > wrote: >>> >>> Hi, Alan. >>> I just found a few side effects in the test. >>> - All other tests(actually all java applications) which are executed >>> after the new test will show colorPanel(until it will not be closed >>> manually). >>> - If the Finder will be opened in full screen(or in the location >>> where the test will show the test windows) then the test will fail. >>> Maybe it is better to use some other application to deactivate the >>> test? Can we implement it using other java application?(you can run >>> the same TestMainKeyWindow.main() and pass some flag to it) >>> >>> >>> On 05/04/2018 16:15, Alan Snyder wrote: >>>> Thank you for your comments. Here is the updated webrev: >>>> http://cr.openjdk.java.net/~serb/alans/8194327/webrev.01/ >>>> Alan >>>>> On Apr 4, 2018, at 9:34 AM, Sergey Bylokhov >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Hi, Alan. >>>>> A few comments about the test: >>>>> - It is a mac specific and JtregNativeJdk should compile it on mac only >>>>> - It should close all windows at the end, currently it leaves >>>>> Finder opened. >>>>> - it tries to use NSWindowStyleMask/NSWindowStyleMaskTitled which >>>>> are available in ?>10.12. We only plan to move to 10.9 soon. So the >>>>> test should skip it or use NSInteger/NSTitledWindowMask for macOS < >>>>> MAC_OS_X_VERSION_10_12. >>>>> - It looks like other tests in JtregNativeJdk.gmk use libtest+Some >>>>> useful name, I suggest to use the same instead of bugid(same for >>>>> the test name "Test.java"). >>>>> BUILD_JDK_JTREG_LIBRARIES_LIBS_libtest819432 >>>>> >>>>> On 02/04/2018 19:35, Alan Snyder wrote: >>>>>> Please review the following change to the macOS AWT. >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194327 >>>>>> Webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.00/ >>>>>> The goal of this change is to allow a Java desktop application on >>>>>> macOS to properly coexist with a native utility panel, such as the >>>>>> native color chooser. >>>>>> The native color chooser is an example of a window that can become >>>>>> the key (focused) window but cannot become the main window. >>>>>> If the previously active window is a Java frame, it should resign >>>>>> key window status (lose focus), but retain the main window status. >>>>>> A window that is main but not key does not own the keyboard focus, >>>>>> but it appears active, and if it is using the screen menu bar, >>>>>> it may be invoked to process a menu item action (if the menu item >>>>>> is not already handled by the key window). >>>>>> The current macOS AWT does not support this combination of window >>>>>> states. A Java window is either key and main, or neither. >>>>>> When the color chooser becomes key (obtains focus), the Java frame >>>>>> resigns both key and main status. >>>>>> This change allows the key window status to be resigned while >>>>>> retaining the main window status, with the appropriate behavior. >>>>>> Note that with this change, it remains impossible to implement a >>>>>> Java window that behaves like the native color chooser (i.e., can >>>>>> become key but not main). >>>>>> That would require a much bigger change. >>>>>> ??Alan >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>> >>> >>> -- >>> Best regards, Sergey. >> > -- Best regards, Sergey. From christoph.langer at sap.com Wed Apr 18 07:08:43 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Apr 2018 07:08:43 +0000 Subject: Proposal:AIX's IME support In-Reply-To: <8062d9b71e62b0fc92ae505be9e08e85@linux.vnet.ibm.com> References: <2ed52f9dc4e9487c7b3131b5af3666d9@linux.vnet.ibm.com> <428f37b3-0a64-b727-2426-9c96fd8155a9@oracle.com> <8062d9b71e62b0fc92ae505be9e08e85@linux.vnet.ibm.com> Message-ID: Hi Ichiroh, I just wanted to let you know that I'm currently working with your patch, e.g. test this on AIX. As I've written to you in direct mails, I don't really like that so much code is duplicated into the AIX subfolders. This can eventually lead to the fact that somebody does fixes in the common branch and AIX will miss it. I'll try to update your patch a bit to integrate better with the common codebase. Best regards Christoph > -----Original Message----- > From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf Of > Ichiroh Takiguchi > Sent: Montag, 16. April 2018 19:42 > To: Sergey Bylokhov > Cc: awt-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: Proposal:AIX's IME support > > Hello. > > Sorry I'm late. > Christoph Langer helped me to put webrev file into cr.openjdk.java.net. > See, http://cr.openjdk.java.net/~clanger/webrevs/8201429.0/ > > Actually, he found *.patch files had unexpected entries, I fixed the > issue. > It seemed that webrev tool could not handle "hg copy" action. > It was reported by, > > http://mail.openjdk.java.net/pipermail/webrev-dev/2018-April/000145.html > So above webrev file should be fine. > > Please let me know if you have any question and suggestion about webrev > file for > AIX's IME support. > > Thanks, > Ichiroh Takiguchi > > On 2018-04-10 07:39, Sergey Bylokhov wrote: > > Hi, Ichiroh. > > Your contribution is welcome. Can you send the change for review as a > > webrev on cr.openjdk.java.net? > > > > On 09/04/2018 02:09, Ichiroh Takiguchi wrote: > >> Hello, > >> IBM would like to propose another Input Method Framework (IMF) > >> implementation against IBM AIX platform. > >> Same IMF implementation was used by IBM Java8 for AIX. > >> IBM would like to contribute this IMF implementation to OpenJDK > >> project. > >> > >> AIX's Input Method Editor (IME) working behavior is not same as > >> Linux's and Solaris' one. > >> On OpenJDK JDK9 for AIX, users cannot input any East Asian character > >> with their locale by this IME. > >> We think this situation is critical. > >> Put modified files under src/java.desktop/aix/* directories in order > >> not to affect the other unix platform. > >> > >> I'd like contribute following 4 files: > >> M make/lib/Awt2dLibraries.gmk > >> A src/java.desktop/aix/classes/sun/awt/X11InputMethod.java > >> A src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c > >> A src/java.desktop/aix/native/libawt_xawt/xawt/XlibWrapper.c > >> > >> We need to apply too many changes including JNI, so we copied > >> following 3 files from unix directory to aix directory: > >> * src/java.desktop/unix/classes/sun/awt/X11InputMethod.java > >> * src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > >> * src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c > >> Then, we modified them. > >> > >> I'd appreciate any feedback please, and how I would go about obtaining > >> a sponsor and contributor? > >> > >> Thanks, > >> Ichiroh Takiguchi > >> IBM Japan, Ltd. > >> From magnus.ihse.bursie at oracle.com Wed Apr 18 08:34:44 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 18 Apr 2018 10:34:44 +0200 Subject: Proposal:AIX's IME support In-Reply-To: References: <2ed52f9dc4e9487c7b3131b5af3666d9@linux.vnet.ibm.com> <428f37b3-0a64-b727-2426-9c96fd8155a9@oracle.com> <8062d9b71e62b0fc92ae505be9e08e85@linux.vnet.ibm.com> Message-ID: > 18 apr. 2018 kl. 09:08 skrev Langer, Christoph : > > Hi Ichiroh, > > I just wanted to let you know that I'm currently working with your patch, e.g. test this on AIX. > > As I've written to you in direct mails, I don't really like that so much code is duplicated into the AIX subfolders. This can eventually lead to the fact that somebody does fixes in the common branch and AIX will miss it. I agree, this is highly unfortunate. :-( We?ve been paying the price for a long time for duplicated code across platforms. Let?s not repeat the same mistake for AIX. While it seems ?safe? for the platform proponent at the moment (?I?m only touching my platform!?), it?s a loss for the OpenJDK project as a whole in the future. /Magnus > I'll try to update your patch a bit to integrate better with the common codebase. > > Best regards > Christoph > >> -----Original Message----- >> From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf Of >> Ichiroh Takiguchi >> Sent: Montag, 16. April 2018 19:42 >> To: Sergey Bylokhov >> Cc: awt-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> Subject: Re: Proposal:AIX's IME support >> >> Hello. >> >> Sorry I'm late. >> Christoph Langer helped me to put webrev file into cr.openjdk.java.net. >> See, http://cr.openjdk.java.net/~clanger/webrevs/8201429.0/ >> >> Actually, he found *.patch files had unexpected entries, I fixed the >> issue. >> It seemed that webrev tool could not handle "hg copy" action. >> It was reported by, >> >> http://mail.openjdk.java.net/pipermail/webrev-dev/2018-April/000145.html >> So above webrev file should be fine. >> >> Please let me know if you have any question and suggestion about webrev >> file for >> AIX's IME support. >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-04-10 07:39, Sergey Bylokhov wrote: >>> Hi, Ichiroh. >>> Your contribution is welcome. Can you send the change for review as a >>> webrev on cr.openjdk.java.net? >>> >>> On 09/04/2018 02:09, Ichiroh Takiguchi wrote: >>>> Hello, >>>> IBM would like to propose another Input Method Framework (IMF) >>>> implementation against IBM AIX platform. >>>> Same IMF implementation was used by IBM Java8 for AIX. >>>> IBM would like to contribute this IMF implementation to OpenJDK >>>> project. >>>> >>>> AIX's Input Method Editor (IME) working behavior is not same as >>>> Linux's and Solaris' one. >>>> On OpenJDK JDK9 for AIX, users cannot input any East Asian character >>>> with their locale by this IME. >>>> We think this situation is critical. >>>> Put modified files under src/java.desktop/aix/* directories in order >>>> not to affect the other unix platform. >>>> >>>> I'd like contribute following 4 files: >>>> M make/lib/Awt2dLibraries.gmk >>>> A src/java.desktop/aix/classes/sun/awt/X11InputMethod.java >>>> A src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c >>>> A src/java.desktop/aix/native/libawt_xawt/xawt/XlibWrapper.c >>>> >>>> We need to apply too many changes including JNI, so we copied >>>> following 3 files from unix directory to aix directory: >>>> * src/java.desktop/unix/classes/sun/awt/X11InputMethod.java >>>> * src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>> * src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c >>>> Then, we modified them. >>>> >>>> I'd appreciate any feedback please, and how I would go about obtaining >>>> a sponsor and contributor? >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> > From takiguc at linux.vnet.ibm.com Wed Apr 18 09:17:27 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 18 Apr 2018 18:17:27 +0900 Subject: Proposal:AIX's IME support In-Reply-To: References: <2ed52f9dc4e9487c7b3131b5af3666d9@linux.vnet.ibm.com> <428f37b3-0a64-b727-2426-9c96fd8155a9@oracle.com> <8062d9b71e62b0fc92ae505be9e08e85@linux.vnet.ibm.com> Message-ID: <8663d11893863e3e63d4671b02ff01f5@linux.vnet.ibm.com> Hello Magnus and Christoph. I think it's not easy to merge AIX IME support code without current code changes... On 2018-04-18 17:34, Magnus Ihse Bursie wrote: >> 18 apr. 2018 kl. 09:08 skrev Langer, Christoph >> : >> >> Hi Ichiroh, >> >> I just wanted to let you know that I'm currently working with your >> patch, e.g. test this on AIX. >> >> As I've written to you in direct mails, I don't really like that so >> much code is duplicated into the AIX subfolders. This can eventually >> lead to the fact that somebody does fixes in the common branch and AIX >> will miss it. > > I agree, this is highly unfortunate. :-( We?ve been paying the price > for a long time for duplicated code across platforms. Let?s not > repeat the same mistake for AIX. > > While it seems ?safe? for the platform proponent at the moment > (?I?m only touching my platform!?), it?s a loss for the > OpenJDK project as a whole in the future. > > /Magnus > >> I'll try to update your patch a bit to integrate better with the >> common codebase. > >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf Of >>> Ichiroh Takiguchi >>> Sent: Montag, 16. April 2018 19:42 >>> To: Sergey Bylokhov >>> Cc: awt-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>> Subject: Re: Proposal:AIX's IME support >>> >>> Hello. >>> >>> Sorry I'm late. >>> Christoph Langer helped me to put webrev file into >>> cr.openjdk.java.net. >>> See, http://cr.openjdk.java.net/~clanger/webrevs/8201429.0/ >>> >>> Actually, he found *.patch files had unexpected entries, I fixed the >>> issue. >>> It seemed that webrev tool could not handle "hg copy" action. >>> It was reported by, >>> >>> http://mail.openjdk.java.net/pipermail/webrev-dev/2018-April/000145.html >>> So above webrev file should be fine. >>> >>> Please let me know if you have any question and suggestion about >>> webrev >>> file for >>> AIX's IME support. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2018-04-10 07:39, Sergey Bylokhov wrote: >>>> Hi, Ichiroh. >>>> Your contribution is welcome. Can you send the change for review as >>>> a >>>> webrev on cr.openjdk.java.net? >>>> >>>> On 09/04/2018 02:09, Ichiroh Takiguchi wrote: >>>>> Hello, >>>>> IBM would like to propose another Input Method Framework (IMF) >>>>> implementation against IBM AIX platform. >>>>> Same IMF implementation was used by IBM Java8 for AIX. >>>>> IBM would like to contribute this IMF implementation to OpenJDK >>>>> project. >>>>> >>>>> AIX's Input Method Editor (IME) working behavior is not same as >>>>> Linux's and Solaris' one. >>>>> On OpenJDK JDK9 for AIX, users cannot input any East Asian >>>>> character >>>>> with their locale by this IME. >>>>> We think this situation is critical. >>>>> Put modified files under src/java.desktop/aix/* directories in >>>>> order >>>>> not to affect the other unix platform. >>>>> >>>>> I'd like contribute following 4 files: >>>>> M make/lib/Awt2dLibraries.gmk >>>>> A src/java.desktop/aix/classes/sun/awt/X11InputMethod.java >>>>> A src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c >>>>> A src/java.desktop/aix/native/libawt_xawt/xawt/XlibWrapper.c >>>>> >>>>> We need to apply too many changes including JNI, so we copied >>>>> following 3 files from unix directory to aix directory: >>>>> * src/java.desktop/unix/classes/sun/awt/X11InputMethod.java >>>>> * src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>> * src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c >>>>> Then, we modified them. >>>>> >>>>> I'd appreciate any feedback please, and how I would go about >>>>> obtaining >>>>> a sponsor and contributor? >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >> From javalists at cbfiddle.com Wed Apr 18 14:55:25 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 18 Apr 2018 07:55:25 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors In-Reply-To: <60f03131-a79d-ed9a-d86d-3ea4be8184c2@oracle.com> References: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> <22D883A4-B362-411D-82F7-76A418487ADE@cbfiddle.com> <35F57A44-F3B1-484B-9A88-66849FFA9E47@cbfiddle.com> <60f03131-a79d-ed9a-d86d-3ea4be8184c2@oracle.com> Message-ID: <2384DD98-D388-4200-96CB-E81D2B054F25@cbfiddle.com> > On Apr 17, 2018, at 6:36 PM, Sergey Bylokhov wrote: > > It is strange that it is visible only in case of color_panel, maybe it is possible to simplify the testcase and replace color_panel by some other NSWIndow? Not strange. The color panel is the only window in the test that supports the window restoration protocol. I have found a simple way to disable that. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.litvinov at oracle.com Wed Apr 18 18:47:15 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Wed, 18 Apr 2018 19:47:15 +0100 Subject: [11] Review request for 8199748: Touch keyboard is not shown, if text component gets focus from other text component In-Reply-To: <2e0c6d5f-2e4d-5f8c-6737-729301e7f44c@oracle.com> References: <2e0c6d5f-2e4d-5f8c-6737-729301e7f44c@oracle.com> Message-ID: <6cffd13d-e61c-1ce6-bcce-d9f3d74a2873@oracle.com> Hello Sergey, Thank you for review of this fix. No, this topic was not earlier discussed in review process of fixes for other bugs on the touch keyboard subject. We deliberately do not show the touch keyboard on "FocusEvent.FOCUS_GAINED" event, because of the following reasons: 1.? This is the behavior observable in other native applications like MS Edge browser, "notepad.exe", "explorer.exe" (File Explorer), Firefox browser. In this applications the touch keyboard is not shown when the text component just gets focus, the touch keyboard is shown after an explicit touch action. 2.? Such behavior is implemented by some classes from .NET Framework and is described on the following web page from Microsoft documentation. Web page URL: https://docs.microsoft.com/en-us/windows/uwp/design/input/keyboard-interactions#appendix This passage from this web page describes such behavior: "If your app sets focus programmatically to a text input control, the touch keyboard is not invoked. This eliminates unexpected behaviors not instigated directly by the user. However, the keyboard does automatically hide when focus is moved programmatically to a non-text input control." 3.? Showing the touch keyboard on "FocusEvent.FOCUS_GAINED" event may lead us to the error in the following scenario: Step 1 - A user touches a text component. Step 2 - ? The text component receives focus. Step 3 -???? The touch keyboard is shown. Step 4 -? ???? The user manually closes the touch keyboard. Step 5 - ?????? The user touches the text component again. Step 6 - ???????? The touch keyboard is not shown, because the focus did not leave the text component and no FOCUS_GAINED was received. Thank you for the suggestion to make "WTookit.compOnxxx" variables as weak references, what should resolve the possible memory leak. I created the new version of the fix for this bug, which includes the changes listed below. Could you please look at the second version of the fix for this bug. Webrev (the 2nd version): http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.01 The 2nd version of the fix resolves the bug in absolutely different way in comparison with the 1st version of the fix and has the following changes: 1)? The variables "WToolkit.compOnTouchDownEvent", "WToolkit.compOnMousePressedEvent" were made instances of "WeakReference". 2)? The variable "NULL_COMPONENT_WR" was introduced to address issue with thread safety with "compOnTouchDownEvent", "compOnMousePressedEvent" variables. 3)? The big "if" expression, which verifies if the component is valid for showing the touch keyboard, was moved into a dedicated method "boolean isComponentValidForTouchKeyboard(Component)". 4)? Checks on equality to "null" were removed from the following "if" expression, because further "instanceof" expressions for both "comp" and "e" variables will also return "false", if these variables equal "null". "1103???????? if ((comp == null) || (e == null)" 5)? The bug itself is resolved by just not hiding the touch keyboard on "FOCUS_LOST", if it is known that the component which gets focus is a text component. This change of the fix addresses the issue described by Alexey Ivanov in a parallel e-mail in the review of this fix, where with the 1st version of the fix the touch keyboard would be hidden, if the focus was shifted to the second text component by pressing "TAB" on the touch keyboard. Thank you, Anton On 17/04/2018 00:48, Sergey Bylokhov wrote: > Hi, Anton. > Maybe this was discussed before, but can you please clarify why we did > not show the keyborad on focus_gain? > > BTW looks like the WTookit.compOnxxx should be a weak references. > > On 16/04/2018 05:03, Anton Litvinov wrote: >> Hello, >> >> Could you please review the following fix for the bug. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199748 >> Webrev: http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.00 >> >> In the fix for JDK-8166772 it was deliberately implemented that the >> touch keyboard is shown only on "MouseEvent.MOUSE_RELEASED" event and >> is hidden on "FocusEvent.FOCUS_LOST" event. >> >> The reason of the bug is the fact that, when the touch keyboard is >> already shown for one text component and a user touches another text >> component, then the following 2 events occur in the presented order: >> 1. "MouseEvent.MOUSE_RELEASED" event arrives. The touch keyboard is >> shown for the new text component. >> 2. "FocusEvent.FOCUS_LOST" event arrives for the previous text >> component. The touch keyboard shown for the new text component >> becomes hidden. >> >> The fix allows not to hide the touch keyboard during processing of >> "FocusEvent.FOCUS_LOST" event, if the touch keyboard has just been >> shown, as a result of processing of "MouseEvent.MOUSE_RELEASED" >> event, for the component which gets focus >> "FocusEvent.getOppositeComponent()". >> >> Thank you, >> Anton > > From shashidhara.veerabhadraiah at oracle.com Thu Apr 19 06:52:09 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Wed, 18 Apr 2018 23:52:09 -0700 (PDT) Subject: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. In-Reply-To: References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default> <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default> <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com> <992a8202-6ac9-4c16-9fe5-c316e314bed5@default> <814c85c6-0d8d-468c-a2af-fefa79e59ef7@default> <66fcf064-b200-4d6d-ac06-b78517074f00@default> <9fd92bf5-113c-782c-92e9-7b061ace2a6c@oracle.com> <27586cbb-be2c-4941-ade4-8493b501542b@default> <410e40d6-e7d7-4b2d-8647-2dbeb8b82c18@default> <4f0dbe63-e640-8183-b136-08da1af3c5cf@oracle.com> <948a2586-88e3-47cf-bf0f-84995eac96da@default> <80c936e4-fd72-437b-970a-4a71117e24f9@default> <636d9ff1-b9ef-4a9e-9a65-b0892e9bfa6b@default> Message-ID: <6e9d1552-d256-4f79-bb07-5b55756d64e1@default> Hi Sergey, I checked with Prashanth on the external input method. It is just same as change the locale and start input the characters in that locale. Once we change the locale it will try to install sogu or other stuffs to get those locale keys. But on the windows 10 it does not install anything but keyboard language is changed and we can start input those characters. So when I checked with input of different locale keys and found that most of them do generate the keyTyped/keyPressed/keyReleased events for the java component which is same as my implementation under this bug. Only for the Chinese input we only get the keyTyped event. I think since we provide the superset I think this problem is solved. So I think my current changes are fine so please let me know if you have any comments on it. Thanks and regards, Shashi -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, April 10, 2018 6:54 AM To: Shashidhara Veerabhadraiah ; Semyon Sadetsky ; awt-dev at openjdk.java.net Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. Hi, Shashi. Did you check what kind of events are generated by the external input methods? Currently input methods works on all platforms and are able to generate some type events for the Unicode symbols which are absent on the keyboard(for example Chinese hieroglyphs) but we already can handle such events(maybe we generate only TYPE events in this case and skip keyPress/keyRelease events). On 25/03/2018 22:53, Shashidhara Veerabhadraiah wrote: > Hi, Please review the updated Webrev containing the requested changes: > > http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.05/ > > I believe this change implements a new feature of Unicode key input and the corresponding key event generation without affecting the existing ascii key input and key event generations. Hence the regression should be less with this change. > > Some notes with respect to implementation: > 1. On linux platform, native api's present only for the extended ascii support and hence no idea of Unicode input in this platform. > 2. On mac platform, I have used the below native api's to implement the Unicode input to a component and key event trigger from the component to the respective key listener. > https://developer.apple.com/documentation/coregraphics/1456120-cgeventkeyboardgetunicodestring > https://developer.apple.com/documentation/coregraphics/1456028-cgeventkeyboardsetunicodestring?language=objc > (Set and get Unicode key is supported via the core graphics event(CGEvent) which is part of the NSEvent structure which is the base structure for event implementation on mac) > 3. On windows platform, I have used the below native api's to perform this job: > https://msdn.microsoft.com/en-us/library/windows/desktop/ms646310(v=vs.85).aspx > (SendInput api supports the Unicode input via the flag KEYEVENTF_UNICODE) > https://msdn.microsoft.com/en-us/library/windows/desktop/ms646271(v=vs.85).aspx > (Upon VK_PACKET, Get and decode the message via GetMessage() and > TranslateMessage(). This produces a WM_CHAR message containing the > respective Unicode key) > > Thanks and regards, > Shashi > > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, November 27, 2017 11:43 PM > To: Shashidhara Veerabhadraiah > ; Semyon Sadetsky > ; awt-dev at openjdk.java.net > Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. > > Hi, Shashi. >>> Also we should check what events are come to the application when >>> this new API will be used. For example if 'm' will be pressed what >>> notifications will be posted to the >>> application?(keyTyped/keyPressed/keyReleased) > > The test is still manual, I suggest to change it to automated and > validate the behavior of "keyTyped/keyPressed/keyReleased". I suggest > to implement it first and check that it works as expected on macOS and > windows. After that we can take a look to the linux platform(For > example I think KeyEvent.getExtendedKeyCodeForChar() should work on > linux, and we can check can it be used in the proposed fix or not) > > On 20/11/2017 21:03, Shashidhara Veerabhadraiah wrote: >> Hi Sergey, Please find the code updates that you asked for. As discussed I have raised an exception for the linux platform as there is no equivalent functions being implemented yet. >> >> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.04/ >> >> shashi >> >> -----Original Message----- >> From: Shashidhara Veerabhadraiah >> Sent: Thursday, November 16, 2017 12:36 PM >> To: Sergey Bylokhov ; Semyon Sadetsky >> ; awt-dev at openjdk.java.net >> Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. >> >> Hi Sergey, Below are my replies: >> >> shashi >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Tuesday, November 14, 2017 3:32 AM >> To: Shashidhara Veerabhadraiah >> ; Semyon Sadetsky >> ; awt-dev at openjdk.java.net >> Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. >> >> Hi, Shashi. >> 115 @Override >> 116 public void keyReleaseUnicode( int key ) { >> 117 // No special functions that implements a unicode key press >> 118 // and release in linux platform. Hence falls back to the >> 119 // default ASCII key press/release functions. >> 120 keyReleaseImpl(key); >> 121 } >> >> We should do something in this part of the fix, because we cannot use unicode point as a keyCode. It will produce incorrect result. >> [Shashi] As discussed in the meeting, will add a unsupported exception in the following Webrev. >> >> Also we should check what events are come to the application when >> this new API will be used. For example if 'm' will be pressed what >> notifications will be posted to the >> application?(keyTyped/keyPressed/keyReleased) >> [Shashi] It sends out the keyPressed/keyReleased events(WM_KEYUP/WM_KEYDOWN) events. The current code takes into account of the Unicode chars and uses the Unicode functions like ::ToUnicodeEx() to scan the characters. >> >> On 05/11/2017 21:04, Shashidhara Veerabhadraiah wrote: >>> Hi Sergey, Please find the updated Webrev addressing your comments/requirements. >>> >>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.03/ >>> >>> Thanks and regards, >>> Shashi >>> >>> -----Original Message----- >>> From: Shashidhara Veerabhadraiah >>> Sent: Friday, October 27, 2017 6:44 PM >>> To: Sergey Bylokhov ; Semyon Sadetsky >>> ; awt-dev at openjdk.java.net >>> Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. >>> >>> Hi Sergey, below are my replies: >>> >>> Thanks and regards, >>> shashi >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: Friday, October 27, 2017 11:47 AM >>> To: Shashidhara Veerabhadraiah >>> ; Semyon Sadetsky >>> ; awt-dev at openjdk.java.net >>> Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. >>> >>> Hi, Shashi. >>> - Do we need to check passed unicode code-point in Robot.java using checkKeycodeArgument(key);? >>> [Shashi] I think yes. If the key value is zero I believe we don't need to process further. >>> - Can you please clarify how it will work on linux where we will use code-point as a keycode? >>> [Shashi] There is no update being done to the linux source code as I could not find native call which can interpret the Unicode. Hence it will behave same as the original keypress() and keyrelease(). >>> - It would be good if the names of the parameters will be unified/corrected, for example: >>> private native void keyEventUnicode(int javaKeyCode, boolean keydown); "javaKeyCode" - Is it a java key code or a Unicode code-point? >>> [Shashi] Sure will update in the coming pass. >>> >>> Why the test is manual? Isn't an application should recognize this new functionality automatically? Additionally it would be good to test all key related listeners(keyTyped/keyPressed/keyReleased). >>> [Shashi] We need to be sure that the Unicode key indeed displayed as the standard Unicode. There is no other way to confirm that it is indeed been the same standard Unicode that's been displayed. >>> >>> Debug code in awt_Robot.cpp >>> if(isUnicode) {printf("In unicode func:%d", jkey); [Shashi] Sure will update in the coming pass. >>> >>> >>> Also I would like to propose an idea for discussion: probably it would be better to create only one Robot#type(codePoint) method? What do you think? >>> [Shashi] It can be done but the only problem is that it is kinda different from the keypress() and keyRelease() functions. If that's fine then it can be done. Please confirm based on that I will produce a new Webrev based on that. >>> >>> On 26/10/2017 21:39, Shashidhara Veerabhadraiah wrote: >>>> Hi Sergey\Semyon, Please do the review for the below bug. >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>>> *From:* Shashidhara Veerabhadraiah >>>> *Sent:* Thursday, September 21, 2017 2:14 PM >>>> *To:* Sergey Bylokhov ; Semyon Sadetsky >>>> ; awt-dev at openjdk.java.net >>>> *Subject:* Re: [10] JDK-8148344: Java robot keypress >>>> should be able to use extended key code characters as ? ? ?. >>>> >>>> Hi All, Please find the updated webrev containing a new test that >>>> is added to test out the software changes that were made under this >>>> enhancement. >>>> >>>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.02/ >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>>> *From:* Shashidhara Veerabhadraiah >>>> *Sent:* Thursday, September 21, 2017 11:37 AM >>>> *To:* Sergey Bylokhov >>> >; Semyon Sadetsky >>>> >; >>>> awt-dev at openjdk.java.net >>>> *Subject:* Re: [10] JDK-8148344: Java robot keypress >>>> should be able to use extended key code characters as ? ? ?. >>>> >>>> Hi Sergey, I was able to input the surrogate pairs and got the >>>> required output as shown below: >>>> >>>> Below is the output after we input the surrogate pairs: >>>> >>>> Thanks and regards, >>>> >>>> Shashi >>>> >>>> -----Original Message----- >>>> From: Sergey Bylokhov >>>> Sent: Thursday, September 14, 2017 11:33 PM >>>> To: Shashidhara Veerabhadraiah >>>> >>> >; Semyon Sadetsky >>>> >; >>>> awt-dev at openjdk.java.net >>>> Subject: Re: [10] JDK-8148344: Java robot keypress should >>>> be able to use extended key code characters as ? ? ?. >>>> >>>> The java uses UTF16, I guess this new api should use it also, and >>>> we should check that the surrogate pairs will be supported. >>>> >>>> On 9/14/17 03:56, Shashidhara Veerabhadraiah wrote: >>>> >>>> > Hi Sergey, Yes it represents the Unicode code point. The >>>> encoding is same as the window characteristic which is UTF 8 as implemented in Java. >>>> >>>> > >>>> >>>> > Thanks and regards, >>>> >>>> > Shashi >>>> >>>> > >>>> >>>> > -----Original Message----- >>>> >>>> > From: Sergey Bylokhov >>>> >>>> > Sent: Wednesday, September 13, 2017 5:22 AM >>>> >>>> > To: Shashidhara Veerabhadraiah >>>> >>>> > >>> >; Semyon Sadetsky >>>> >>>> > >>> >; >>>> awt-dev at openjdk.java.net >>>> >>>> > Subject: Re: [10] JDK-8148344: Java robot keypress >>>> should be able to use extended key code characters as ? ? ?. >>>> >>>> > >>>> >>>> > Hi, Shashi. >>>> >>>> > One initial question: >>>> >>>> > What is an int parameter of these methods means, is it a >>>> "Unicode code point"? What encoding utf8/utf16 should be used? >>>> >>>> > >>>> >>>> > On 9/8/17 02:50, Shashidhara Veerabhadraiah wrote: >>>> >>>> >> Hi, I have updated the Webrev to accommodate the comments >>>> and here is >>>> >>>> >> the new Webrev: >>>> >>>> >> >>>> >>>> >> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.01/ >>>> >>>> >> >>>> >>>> >> I have separated the /_Unicode_/ keys input via java robot >>>> as a new >>>> >>>> >> set of /_public_/ api?s (this is in similar fashion as how >>>> the >>>> >>>> >> platform offers the Unicode keys input into the system) and >>>> this has >>>> >>>> >> been tested on all the platforms using the test file similar >>>> to the >>>> >>>> >> attached file in the bug. A more proper test file would be >>>> put for >>>> >>>> >> review in the subsequent reviews. >>>> >>>> >> >>>> >>>> >> Thanks and regards, >>>> >>>> >> >>>> >>>> >> Shashi >>>> >>>> >> >>>> >>>> >> *From:* Sergey Bylokhov >>>> >>>> >> *Sent:* Wednesday, August 30, 2017 2:33 AM >>>> >>>> >> *To:* Shashidhara Veerabhadraiah >>>> >>>> >> >>> > >>>> >>>> >> *Cc:* awt-dev at openjdk.java.net >>>> >>>> >>>> >> *Subject:* Re: [10] JDK-8148344: Java robot >>>> keypress should >>>> >>>> >> be able to use extended key code characters as ? ? ?. >>>> >>>> >> >>>> >>>> >> Hi, Shashi. >>>> >>>> >> >>>> >>>> >> This is part of this fix, to figure out how it will work for >>>> external >>>> >>>> >> applications. As you said this functionally can be useful >>>> for an >>>> >>>> >> onscreen keyboards, which virtually can have any possible >>>> keys, but >>>> >>>> >> we should check how the applications will react on such keys: >>>> >>>> >>?? ?- Will the application get some kind of keyPress/Release? >>>> >>>> >>?? ?- Will the application get some keyCode for such event? >>>> >>>> >>?? ?- Is it possible to get autorepeat for such keys?(between >>>> >>>> >> press/release) >>>> >>>> >> >>>> >>>> >> Depending from the answers above we can enhance existed >>>> robot API or >>>> >>>> >> provide a new one: >>>> >>>> >> like Robot.keyType(char)/etc >>>> >>>> >> >>>> >>>> >> ----- shashidhara.veerabhadraiah at oracle.com >>>> >>>> >>>> >> wrote: >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >> Hi Sergey, I was only able to add short cut keys in the >>>> Microsoft >>>> >>>> >> word but not as a system wide short cut key. There was no >>>> mechanism >>>> >>>> >> that I could find to add a short cut key for a Unicode char!! >>>> Can you >>>> >>>> >> please tell me the steps to do the same if you are aware of? >>>> >>>> >> >>>> >>>> >> Thanks and regards, >>>> >>>> >> >>>> >>>> >> shashi >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >> *From:*Sergey Bylokhov >>>> >>>> >>> *Sent:* Tuesday, August 22, 2017 8:34 PM >>>> >>>> >>> *To:* Shashidhara Veerabhadraiah >>>> >>>> >>> >>> >>>> >> > >>>> >>>> >>> *Cc:* awt-dev at openjdk.java.net >>>> >>>> >>>> >>> *Subject:* Re: [10] JDK-8148344: Java robot >>>> keypress >>>> >>>> >>> should be >>>> >>>> >> able to use extended key code characters as ? ? ?. >>>> >>>> >> >>>> >>>> >> Hi, Shashi. >>>> >>>> >>> Can you check how this Robot API will work when the >>>> application will have a shortcut for such key? Will such shortcuts >>>> will work after this fix? >>>> >>>> >>> >>>> >>>> >>> ----- shashidhara.veerabhadraiah at oracle.com >>>> >>>> >>>> >> wrote: >>>> >>>> >>>> >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >>> >>>> >>>> >> >>>> >>>> >> Hi All, Please review fix for the /_enhancement_/ wherein >>>> the robot >>>> >>>> >> key press of non-ascii were interpreted as question marks. >>>> >>>> >> >>>> >>>> >> Issue: The robot key press events was handling only the >>>> ascii inputs >>>> >>>> >> and ignored the other Unicode inputs. Either it was throwing >>>> illegal >>>> >>>> >> argument exception in windows or does nothing on the mac for >>>> those >>>> >>>> >> Unicode inputs. >>>> >>>> >> >>>> >>>> >> Solution and fix: The platform specific api?s was unable >>>> handle the >>>> >>>> >> non-ascii inputs. I have modified the api?s to accept the >>>> non-ascii >>>> >>>> >> inputs and correspondingly send the message to the window to >>>> print >>>> >>>> >> the non-ascii characters as well. Below is the picture of >>>> how the >>>> >>>> >> non-ascii inputs are considered and printed onto the window. >>>> >>>> >> >>>> >>>> >> The solution spans across windows and mac platform and still >>>> in >>>> >>>> >> search of a solution for the Linux platform. The solution >>>> implements >>>> >>>> >> key scanning only upon existing valid ascii key was /_not_/ >>>> found and >>>> >>>> >> assumes it as Unicode key and sends the event to event queue >>>> to be >>>> >>>> >> processed as Unicode keys. Different formats are being used >>>> by >>>> >>>> >> different platform implementation of Unicode. For ex., per >>>> the below >>>> >>>> >> Unicode list, in the case of windows and mac, the key input >>>> can take >>>> >>>> >> decimal values whereas on Linux it can only take the Code values. >>>> >>>> >> >>>> >>>> >> On Linux, I was able to get the KeySym of Unicode keys but >>>> was unable >>>> >>>> >> to fake the key event as there was no mechanism available >>>> for the >>>> >>>> >> same(which sends the key event to window). Please let me >>>> know if >>>> >>>> >> there is any such mechanism available to simulate Unicode >>>> key events >>>> >>>> >> on Linux platform. Hence I think to raise a bug for the >>>> Linux >>>> >>>> >> platform and close this JDK-8148344 bug. >>>> >>>> >> >>>> >>>> >> Enhancement id: >>>> https://bugs.openjdk.java.net/browse/JDK-8148344 >>>> >>>> >> >>>> >>>> >> Webrev: >>>> http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.00/ >>>> >>>> >> >>>> >>>> >> Thanks and regards, >>>> >>>> >> >>>> >>>> >> Shashi >>>> >>>> >> >>>> >>>> > >>>> >>>> > >>>> >>>> > -- >>>> >>>> > Best regards, Sergey. >>>> >>>> > >>>> >>>> -- >>>> >>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From anton.litvinov at oracle.com Thu Apr 19 11:12:27 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Thu, 19 Apr 2018 12:12:27 +0100 Subject: [11] Review request for 8199748: Touch keyboard is not shown, if text component gets focus from other text component In-Reply-To: <019c5cd2-367d-6c26-aa88-69cb5c68c217@oracle.com> References: <019c5cd2-367d-6c26-aa88-69cb5c68c217@oracle.com> Message-ID: <3c04a4d9-001f-abf3-0501-a87fc8decbba@oracle.com> Hello Alexey, Thank you for review of this fix and for identification of this issue. Yes, I agree that the touch keyboard should not be hidden, when a focus is moved from one text component to the second, after the TAB key was pressed on the touch keyboard. Hiding it in this scenario, while not hiding the touch keyboard after touching the area of the second text component, is inconsistent. The new version of the fix addressing your remark was created. Webrev (the 2nd version): http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.01 This issue and the original bug is resolved in the 2nd version of the fix by not calling "WToolkit.hideTouchKeyboard()" on "FocusEvent.FOCUS_LOST" event, if a component which gets focus is a text component. Also this version of the fix contains resolution of a possible memory leak from the variables: "compOnTouchDownEvent", "compOnMousePressedEvent" by changing their types to "WeakReference" and contains small refactoring of "if" expressions in "WToolkit.showOrHideTouchKeyboard(Component, AWTEvent)" method. Could you please look at the 2nd version of the fix. Thank you, Anton On 17/04/2018 17:24, Alexey Ivanov wrote: > Hi Anton, > > Shouldn't touch keyboard remain visible if Tab key on the touch > keyboard itself is pressed? Provided the next focusable component is a > text component, of course. > > Consider the following scenario: start Notepad and open Replace > dialog. Touch "Find what" field: the touch keyboard appears. Press Tab > on the touch keyboard: the focus moves to "Replace with" field and > touch keyboard stays visible. > > > Regards, > Alexey > > On 16/04/2018 13:03, Anton Litvinov wrote: >> Hello, >> >> Could you please review the following fix for the bug. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8199748 >> Webrev: http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.00 >> >> In the fix for JDK-8166772 it was deliberately implemented that the >> touch keyboard is shown only on "MouseEvent.MOUSE_RELEASED" event and >> is hidden on "FocusEvent.FOCUS_LOST" event. >> >> The reason of the bug is the fact that, when the touch keyboard is >> already shown for one text component and a user touches another text >> component, then the following 2 events occur in the presented order: >> 1. "MouseEvent.MOUSE_RELEASED" event arrives. The touch keyboard is >> shown for the new text component. >> 2. "FocusEvent.FOCUS_LOST" event arrives for the previous text >> component. The touch keyboard shown for the new text component >> becomes hidden. >> >> The fix allows not to hide the touch keyboard during processing of >> "FocusEvent.FOCUS_LOST" event, if the touch keyboard has just been >> shown, as a result of processing of "MouseEvent.MOUSE_RELEASED" >> event, for the component which gets focus >> "FocusEvent.getOppositeComponent()". >> >> Thank you, >> Anton > From alexey.ivanov at oracle.com Fri Apr 20 09:46:26 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 20 Apr 2018 10:46:26 +0100 Subject: [11] Review request for 8199748: Touch keyboard is not shown, if text component gets focus from other text component In-Reply-To: <3c04a4d9-001f-abf3-0501-a87fc8decbba@oracle.com> References: <019c5cd2-367d-6c26-aa88-69cb5c68c217@oracle.com> <3c04a4d9-001f-abf3-0501-a87fc8decbba@oracle.com> Message-ID: <98b3163f-4a7f-87a5-4c16-37ccc953b6dc@oracle.com> Hi Anton, The fix looks good. Could you please add space after the cast operator before pushing? No additional review is required for this small code style change, I believe. Regards, Alexey On 19/04/2018 12:12, Anton Litvinov wrote: > Hello Alexey, > > Thank you for review of this fix and for identification of this issue. > Yes, I agree that the touch keyboard should not be hidden, when a > focus is moved from one text component to the second, after the TAB > key was pressed on the touch keyboard. Hiding it in this scenario, > while not hiding the touch keyboard after touching the area of the > second text component, is inconsistent. > > The new version of the fix addressing your remark was created. > > Webrev (the 2nd version): > http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.01 > > This issue and the original bug is resolved in the 2nd version of the > fix by not calling "WToolkit.hideTouchKeyboard()" on > "FocusEvent.FOCUS_LOST" event, if a component which gets focus is a > text component. Also this version of the fix contains resolution of a > possible memory leak from the variables: "compOnTouchDownEvent", > "compOnMousePressedEvent" by changing their types to > "WeakReference" and contains small refactoring of "if" > expressions in "WToolkit.showOrHideTouchKeyboard(Component, AWTEvent)" > method. Could you please look at the 2nd version of the fix. > > Thank you, > Anton > > On 17/04/2018 17:24, Alexey Ivanov wrote: >> Hi Anton, >> >> Shouldn't touch keyboard remain visible if Tab key on the touch >> keyboard itself is pressed? Provided the next focusable component is >> a text component, of course. >> >> Consider the following scenario: start Notepad and open Replace >> dialog. Touch "Find what" field: the touch keyboard appears. Press >> Tab on the touch keyboard: the focus moves to "Replace with" field >> and touch keyboard stays visible. >> >> >> Regards, >> Alexey >> >> On 16/04/2018 13:03, Anton Litvinov wrote: >>> Hello, >>> >>> Could you please review the following fix for the bug. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199748 >>> Webrev: http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.00 >>> >>> In the fix for JDK-8166772 it was deliberately implemented that the >>> touch keyboard is shown only on "MouseEvent.MOUSE_RELEASED" event >>> and is hidden on "FocusEvent.FOCUS_LOST" event. >>> >>> The reason of the bug is the fact that, when the touch keyboard is >>> already shown for one text component and a user touches another text >>> component, then the following 2 events occur in the presented order: >>> 1. "MouseEvent.MOUSE_RELEASED" event arrives. The touch keyboard is >>> shown for the new text component. >>> 2. "FocusEvent.FOCUS_LOST" event arrives for the previous text >>> component. The touch keyboard shown for the new text component >>> becomes hidden. >>> >>> The fix allows not to hide the touch keyboard during processing of >>> "FocusEvent.FOCUS_LOST" event, if the touch keyboard has just been >>> shown, as a result of processing of "MouseEvent.MOUSE_RELEASED" >>> event, for the component which gets focus >>> "FocusEvent.getOppositeComponent()". >>> >>> Thank you, >>> Anton >> > From anton.litvinov at oracle.com Fri Apr 20 13:30:52 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Fri, 20 Apr 2018 14:30:52 +0100 Subject: [11] Review request for 8199748: Touch keyboard is not shown, if text component gets focus from other text component In-Reply-To: <98b3163f-4a7f-87a5-4c16-37ccc953b6dc@oracle.com> References: <019c5cd2-367d-6c26-aa88-69cb5c68c217@oracle.com> <3c04a4d9-001f-abf3-0501-a87fc8decbba@oracle.com> <98b3163f-4a7f-87a5-4c16-37ccc953b6dc@oracle.com> Message-ID: <0bc93c7f-fcb2-e6f0-9ffe-9bfb8cc08666@oracle.com> Hello Alexey, Thank you for approval of the 2nd version of the fix. I understand your recommendation to add space character in class cast expressions, for example to make the expression ??? 1109???????????????????? ((TextComponent)comp).isEditable()) || look as ??? 1109???????????????????? ((TextComponent) comp).isEditable()) || But in case of this fix it will be necessary to apply this change to other code related to the fix, like: ??? 1125???????????? MouseEvent me = (MouseEvent)e; ??? 1146???????????? FocusEvent fe = (FocusEvent)e; In fact, I have never used the style of formatting suggested by you in my previous fixes before, and nobody before recommended me to follow this style with extra space in class cast expressions. Also I did not see this style was widely used in AWT code, except for the class "WToolkit", where I see many examples of it for the first time. Personally I do not like this extra space, but, if you insist and just for the purpose of making formatting style of this fix comply with other code only in "WTookit.java" file, I could add these extra spaces before pushing the fix, if the fix is approved by Sergey Bylokhov. Thank you, Anton On 20/04/2018 10:46, Alexey Ivanov wrote: > Hi Anton, > > The fix looks good. > > Could you please add space after the cast operator before pushing? > No additional review is required for this small code style change, I > believe. > > Regards, > Alexey > > On 19/04/2018 12:12, Anton Litvinov wrote: >> Hello Alexey, >> >> Thank you for review of this fix and for identification of this >> issue. Yes, I agree that the touch keyboard should not be hidden, >> when a focus is moved from one text component to the second, after >> the TAB key was pressed on the touch keyboard. Hiding it in this >> scenario, while not hiding the touch keyboard after touching the area >> of the second text component, is inconsistent. >> >> The new version of the fix addressing your remark was created. >> >> Webrev (the 2nd version): >> http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.01 >> >> This issue and the original bug is resolved in the 2nd version of the >> fix by not calling "WToolkit.hideTouchKeyboard()" on >> "FocusEvent.FOCUS_LOST" event, if a component which gets focus is a >> text component. Also this version of the fix contains resolution of a >> possible memory leak from the variables: "compOnTouchDownEvent", >> "compOnMousePressedEvent" by changing their types to >> "WeakReference" and contains small refactoring of "if" >> expressions in "WToolkit.showOrHideTouchKeyboard(Component, >> AWTEvent)" method. Could you please look at the 2nd version of the fix. >> >> Thank you, >> Anton >> >> On 17/04/2018 17:24, Alexey Ivanov wrote: >>> Hi Anton, >>> >>> Shouldn't touch keyboard remain visible if Tab key on the touch >>> keyboard itself is pressed? Provided the next focusable component is >>> a text component, of course. >>> >>> Consider the following scenario: start Notepad and open Replace >>> dialog. Touch "Find what" field: the touch keyboard appears. Press >>> Tab on the touch keyboard: the focus moves to "Replace with" field >>> and touch keyboard stays visible. >>> >>> >>> Regards, >>> Alexey >>> >>> On 16/04/2018 13:03, Anton Litvinov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix for the bug. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199748 >>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.00 >>>> >>>> In the fix for JDK-8166772 it was deliberately implemented that the >>>> touch keyboard is shown only on "MouseEvent.MOUSE_RELEASED" event >>>> and is hidden on "FocusEvent.FOCUS_LOST" event. >>>> >>>> The reason of the bug is the fact that, when the touch keyboard is >>>> already shown for one text component and a user touches another >>>> text component, then the following 2 events occur in the presented >>>> order: >>>> 1. "MouseEvent.MOUSE_RELEASED" event arrives. The touch keyboard is >>>> shown for the new text component. >>>> 2. "FocusEvent.FOCUS_LOST" event arrives for the previous text >>>> component. The touch keyboard shown for the new text component >>>> becomes hidden. >>>> >>>> The fix allows not to hide the touch keyboard during processing of >>>> "FocusEvent.FOCUS_LOST" event, if the touch keyboard has just been >>>> shown, as a result of processing of "MouseEvent.MOUSE_RELEASED" >>>> event, for the component which gets focus >>>> "FocusEvent.getOppositeComponent()". >>>> >>>> Thank you, >>>> Anton >>> >> > From anton.tarasov at jetbrains.com Fri Apr 20 15:51:31 2018 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Fri, 20 Apr 2018 18:51:31 +0300 Subject: [11] Review request for 8202084: [win] IME candidate window wrong position Message-ID: <5c0669e6-bfd6-6a7f-0063-6370c3e8f7f0@jetbrains.com> Hello! Could you please review the fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8202084 webrev: http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.0 There are two problems: 1) IME candidate window x/y is not scaled. 2) The ancestor window for IME is not the current window when it's "a simple window", but the focus proxy (the owner). Thanks, Anton. From kevin.rushforth at oracle.com Fri Apr 20 16:19:05 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Apr 2018 09:19:05 -0700 Subject: [11] Review request for 8202084: [win] IME candidate window wrong position In-Reply-To: <5c0669e6-bfd6-6a7f-0063-6370c3e8f7f0@jetbrains.com> References: <5c0669e6-bfd6-6a7f-0063-6370c3e8f7f0@jetbrains.com> Message-ID: <2874db52-e105-d858-4291-0ea6eed5c8b2@oracle.com> I think the first of these problems is the same as: https://bugs.openjdk.java.net/browse/JDK-8189687 Can you please check that and close JDK-8189687 as a duplicate if so? Thanks. -- Kevin On 4/20/2018 8:51 AM, Anton Tarasov wrote: > Hello! > > Could you please review the fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202084 > webrev: http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.0 > > There are two problems: > 1) IME candidate window x/y is not scaled. > 2) The ancestor window for IME is not the current window when it's "a > simple window", but the focus proxy (the owner). > > Thanks, > Anton. From anton.tarasov at jetbrains.com Fri Apr 20 16:28:12 2018 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Fri, 20 Apr 2018 19:28:12 +0300 Subject: [11] Review request for 8202084: [win] IME candidate window wrong position In-Reply-To: <2874db52-e105-d858-4291-0ea6eed5c8b2@oracle.com> References: <5c0669e6-bfd6-6a7f-0063-6370c3e8f7f0@jetbrains.com> <2874db52-e105-d858-4291-0ea6eed5c8b2@oracle.com> Message-ID: <61b760f3-4810-dd8f-c100-7de642ecfaf6@jetbrains.com> Hi Kevin, Thanks for pointing (I didn't find it). Closed it as duplicate. Regards, Anton. On 4/20/2018 7:19 PM, Kevin Rushforth wrote: > I think the first of these problems is the same as: > > https://bugs.openjdk.java.net/browse/JDK-8189687 > > Can you please check that and close JDK-8189687 as a duplicate if so? > > Thanks. > > -- Kevin > > > On 4/20/2018 8:51 AM, Anton Tarasov wrote: >> Hello! >> >> Could you please review the fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202084 >> webrev: http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.0 >> >> There are two problems: >> 1) IME candidate window x/y is not scaled. >> 2) The ancestor window for IME is not the current window when it's "a >> simple window", but the focus proxy (the owner). >> >> Thanks, >> Anton. > From kevin.rushforth at oracle.com Fri Apr 20 16:37:43 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Apr 2018 09:37:43 -0700 Subject: [11] Review request for 8202084: [win] IME candidate window wrong position In-Reply-To: <61b760f3-4810-dd8f-c100-7de642ecfaf6@jetbrains.com> References: <5c0669e6-bfd6-6a7f-0063-6370c3e8f7f0@jetbrains.com> <2874db52-e105-d858-4291-0ea6eed5c8b2@oracle.com> <61b760f3-4810-dd8f-c100-7de642ecfaf6@jetbrains.com> Message-ID: Thanks, Anton. -- Kevin On 4/20/2018 9:28 AM, Anton Tarasov wrote: > Hi Kevin, > > Thanks for pointing (I didn't find it). Closed it as duplicate. > > Regards, > Anton. > > On 4/20/2018 7:19 PM, Kevin Rushforth wrote: >> I think the first of these problems is the same as: >> >> https://bugs.openjdk.java.net/browse/JDK-8189687 >> >> Can you please check that and close JDK-8189687 as a duplicate if so? >> >> Thanks. >> >> -- Kevin >> >> >> On 4/20/2018 8:51 AM, Anton Tarasov wrote: >>> Hello! >>> >>> Could you please review the fix: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202084 >>> webrev: http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.0 >>> >>> There are two problems: >>> 1) IME candidate window x/y is not scaled. >>> 2) The ancestor window for IME is not the current window when it's >>> "a simple window", but the focus proxy (the owner). >>> >>> Thanks, >>> Anton. >> > From kevin.rushforth at oracle.com Fri Apr 20 16:43:00 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Apr 2018 09:43:00 -0700 Subject: [11] Review request for 8202084: [win] IME candidate window wrong position In-Reply-To: <61b760f3-4810-dd8f-c100-7de642ecfaf6@jetbrains.com> References: <5c0669e6-bfd6-6a7f-0063-6370c3e8f7f0@jetbrains.com> <2874db52-e105-d858-4291-0ea6eed5c8b2@oracle.com> <61b760f3-4810-dd8f-c100-7de642ecfaf6@jetbrains.com> Message-ID: I just noticed that there was in in-progress review for JDK-8189687 on swing-dev [1]. Maybe Prasanta can comment on the state of that review and also review your fix. -- Kevin [1] http://mail.openjdk.java.net/pipermail/swing-dev/2018-March/008462.html On 4/20/2018 9:28 AM, Anton Tarasov wrote: > Hi Kevin, > > Thanks for pointing (I didn't find it). Closed it as duplicate. > > Regards, > Anton. > > On 4/20/2018 7:19 PM, Kevin Rushforth wrote: >> I think the first of these problems is the same as: >> >> https://bugs.openjdk.java.net/browse/JDK-8189687 >> >> Can you please check that and close JDK-8189687 as a duplicate if so? >> >> Thanks. >> >> -- Kevin >> >> >> On 4/20/2018 8:51 AM, Anton Tarasov wrote: >>> Hello! >>> >>> Could you please review the fix: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202084 >>> webrev: http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.0 >>> >>> There are two problems: >>> 1) IME candidate window x/y is not scaled. >>> 2) The ancestor window for IME is not the current window when it's >>> "a simple window", but the focus proxy (the owner). >>> >>> Thanks, >>> Anton. >> > From alexey.ivanov at oracle.com Fri Apr 20 18:16:20 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 20 Apr 2018 19:16:20 +0100 Subject: [11] Review request for 8199748: Touch keyboard is not shown, if text component gets focus from other text component In-Reply-To: <0bc93c7f-fcb2-e6f0-9ffe-9bfb8cc08666@oracle.com> References: <019c5cd2-367d-6c26-aa88-69cb5c68c217@oracle.com> <3c04a4d9-001f-abf3-0501-a87fc8decbba@oracle.com> <98b3163f-4a7f-87a5-4c16-37ccc953b6dc@oracle.com> <0bc93c7f-fcb2-e6f0-9ffe-9bfb8cc08666@oracle.com> Message-ID: <29c90708-a97d-5bf9-9d80-3f88078e6ef6@oracle.com> Hi Anton, I implied the space after the cast would be added in all the cases where cast is used in this code. I don't insist: both styles are used throughout AWT and Swing; even in WToolkit.java both are used. I'm not for strictly following guidelines but for consistency. The closest functions with casts to your code are grab() and ungrab(). In both cases, there's a space after cast. Sergey Bylokhov has added the space as part of JDK-8074028 [1][2]. However, Code Conventions for the Java? Programming Language [3] recommends using space after cast. Regards, Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8074028 [2] http://hg.openjdk.java.net/jdk9/client/jdk/rev/39bd7fa12bc3#l83.35 [3] http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#682 On 20/04/2018 14:30, Anton Litvinov wrote: > Hello Alexey, > > Thank you for approval of the 2nd version of the fix. I understand > your recommendation to add space character in class cast expressions, > for example to make the expression > > ??? 1109???????????????????? ((TextComponent)comp).isEditable()) || > > look as > > ??? 1109???????????????????? ((TextComponent) comp).isEditable()) || > > But in case of this fix it will be necessary to apply this change to > other code related to the fix, like: > > ??? 1125???????????? MouseEvent me = (MouseEvent)e; > ??? 1146???????????? FocusEvent fe = (FocusEvent)e; > > In fact, I have never used the style of formatting suggested by you in > my previous fixes before, and nobody before recommended me to follow > this style with extra space in class cast expressions. Also I did not > see this style was widely used in AWT code, except for the class > "WToolkit", where I see many examples of it for the first time. > Personally I do not like this extra space, but, if you insist and just > for the purpose of making formatting style of this fix comply with > other code only in "WTookit.java" file, I could add these extra spaces > before pushing the fix, if the fix is approved by Sergey Bylokhov. > > Thank you, > Anton > > On 20/04/2018 10:46, Alexey Ivanov wrote: >> Hi Anton, >> >> The fix looks good. >> >> Could you please add space after the cast operator before pushing? >> No additional review is required for this small code style change, I >> believe. >> >> Regards, >> Alexey >> >> On 19/04/2018 12:12, Anton Litvinov wrote: >>> Hello Alexey, >>> >>> Thank you for review of this fix and for identification of this >>> issue. Yes, I agree that the touch keyboard should not be hidden, >>> when a focus is moved from one text component to the second, after >>> the TAB key was pressed on the touch keyboard. Hiding it in this >>> scenario, while not hiding the touch keyboard after touching the >>> area of the second text component, is inconsistent. >>> >>> The new version of the fix addressing your remark was created. >>> >>> Webrev (the 2nd version): >>> http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.01 >>> >>> This issue and the original bug is resolved in the 2nd version of >>> the fix by not calling "WToolkit.hideTouchKeyboard()" on >>> "FocusEvent.FOCUS_LOST" event, if a component which gets focus is a >>> text component. Also this version of the fix contains resolution of >>> a possible memory leak from the variables: "compOnTouchDownEvent", >>> "compOnMousePressedEvent" by changing their types to >>> "WeakReference" and contains small refactoring of "if" >>> expressions in "WToolkit.showOrHideTouchKeyboard(Component, >>> AWTEvent)" method. Could you please look at the 2nd version of the fix. >>> >>> Thank you, >>> Anton >>> >>> On 17/04/2018 17:24, Alexey Ivanov wrote: >>>> Hi Anton, >>>> >>>> Shouldn't touch keyboard remain visible if Tab key on the touch >>>> keyboard itself is pressed? Provided the next focusable component >>>> is a text component, of course. >>>> >>>> Consider the following scenario: start Notepad and open Replace >>>> dialog. Touch "Find what" field: the touch keyboard appears. Press >>>> Tab on the touch keyboard: the focus moves to "Replace with" field >>>> and touch keyboard stays visible. >>>> >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 16/04/2018 13:03, Anton Litvinov wrote: >>>>> Hello, >>>>> >>>>> Could you please review the following fix for the bug. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199748 >>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.00 >>>>> >>>>> In the fix for JDK-8166772 it was deliberately implemented that >>>>> the touch keyboard is shown only on "MouseEvent.MOUSE_RELEASED" >>>>> event and is hidden on "FocusEvent.FOCUS_LOST" event. >>>>> >>>>> The reason of the bug is the fact that, when the touch keyboard is >>>>> already shown for one text component and a user touches another >>>>> text component, then the following 2 events occur in the presented >>>>> order: >>>>> 1. "MouseEvent.MOUSE_RELEASED" event arrives. The touch keyboard >>>>> is shown for the new text component. >>>>> 2. "FocusEvent.FOCUS_LOST" event arrives for the previous text >>>>> component. The touch keyboard shown for the new text component >>>>> becomes hidden. >>>>> >>>>> The fix allows not to hide the touch keyboard during processing of >>>>> "FocusEvent.FOCUS_LOST" event, if the touch keyboard has just been >>>>> shown, as a result of processing of "MouseEvent.MOUSE_RELEASED" >>>>> event, for the component which gets focus >>>>> "FocusEvent.getOppositeComponent()". >>>>> >>>>> Thank you, >>>>> Anton >>>> >>> >> > From anton.tarasov at jetbrains.com Fri Apr 20 19:27:55 2018 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Fri, 20 Apr 2018 22:27:55 +0300 Subject: [11] Review request for 8202084: [win] IME candidate window wrong position In-Reply-To: References: <5c0669e6-bfd6-6a7f-0063-6370c3e8f7f0@jetbrains.com> <2874db52-e105-d858-4291-0ea6eed5c8b2@oracle.com> <61b760f3-4810-dd8f-c100-7de642ecfaf6@jetbrains.com> Message-ID: <409995c0-489a-1e49-fa18-cd597d19632a@jetbrains.com> Thanks, Kevin, I replied to the ongoing review (sorry for missing it). Anton. On 4/20/2018 7:43 PM, Kevin Rushforth wrote: > I just noticed that there was in in-progress review for JDK-8189687 on > swing-dev [1]. Maybe Prasanta can comment on the state of that review > and also review your fix. > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/swing-dev/2018-March/008462.html > > > On 4/20/2018 9:28 AM, Anton Tarasov wrote: >> Hi Kevin, >> >> Thanks for pointing (I didn't find it). Closed it as duplicate. >> >> Regards, >> Anton. >> >> On 4/20/2018 7:19 PM, Kevin Rushforth wrote: >>> I think the first of these problems is the same as: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8189687 >>> >>> Can you please check that and close JDK-8189687 as a duplicate if so? >>> >>> Thanks. >>> >>> -- Kevin >>> >>> >>> On 4/20/2018 8:51 AM, Anton Tarasov wrote: >>>> Hello! >>>> >>>> Could you please review the fix: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202084 >>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.0 >>>> >>>> There are two problems: >>>> 1) IME candidate window x/y is not scaled. >>>> 2) The ancestor window for IME is not the current window when it's >>>> "a simple window", but the focus proxy (the owner). >>>> >>>> Thanks, >>>> Anton. >>> >> > From anton.litvinov at oracle.com Mon Apr 23 15:20:17 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Mon, 23 Apr 2018 16:20:17 +0100 Subject: [11] Review request for 8199748: Touch keyboard is not shown, if text component gets focus from other text component In-Reply-To: <29c90708-a97d-5bf9-9d80-3f88078e6ef6@oracle.com> References: <019c5cd2-367d-6c26-aa88-69cb5c68c217@oracle.com> <3c04a4d9-001f-abf3-0501-a87fc8decbba@oracle.com> <98b3163f-4a7f-87a5-4c16-37ccc953b6dc@oracle.com> <0bc93c7f-fcb2-e6f0-9ffe-9bfb8cc08666@oracle.com> <29c90708-a97d-5bf9-9d80-3f88078e6ef6@oracle.com> Message-ID: Hi Alexey, Since you insist so much on adding this space character, I am doing this, however, I think that absence of this space character would not influence readability, is purely a matter of personal preference and habits of the programmer. The 3rd version of the fix, which is identical to the 2nd version with the exception of added 4 spaces in 4 places listed below, was created. Webrev (the 3rd version): http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.02 Source code lines, where this space character was introduced: - 1109???????????? ((TextComponent) comp).isEditable()) || - 1111???????????? ((JTextComponent) comp).isEditable()))) { - 1125???????????? MouseEvent me = (MouseEvent) e; - 1146???????????? FocusEvent fe = (FocusEvent) e; Regards, Anton On 20/04/2018 19:16, Alexey Ivanov wrote: > Hi Anton, > > I implied the space after the cast would be added in all the cases > where cast is used in this code. > > I don't insist: both styles are used throughout AWT and Swing; even in > WToolkit.java both are used. > > I'm not for strictly following guidelines but for consistency. The > closest functions with casts to your code are grab() and ungrab(). In > both cases, there's a space after cast. Sergey Bylokhov has added the > space as part of JDK-8074028 [1][2]. > > However, Code Conventions for the Java? Programming Language [3] > recommends using space after cast. > > Regards, > Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8074028 > [2] http://hg.openjdk.java.net/jdk9/client/jdk/rev/39bd7fa12bc3#l83.35 > [3] > http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#682 > > On 20/04/2018 14:30, Anton Litvinov wrote: >> Hello Alexey, >> >> Thank you for approval of the 2nd version of the fix. I understand >> your recommendation to add space character in class cast expressions, >> for example to make the expression >> >> ??? 1109???????????????????? ((TextComponent)comp).isEditable()) || >> >> look as >> >> ??? 1109???????????????????? ((TextComponent) comp).isEditable()) || >> >> But in case of this fix it will be necessary to apply this change to >> other code related to the fix, like: >> >> ??? 1125???????????? MouseEvent me = (MouseEvent)e; >> ??? 1146???????????? FocusEvent fe = (FocusEvent)e; >> >> In fact, I have never used the style of formatting suggested by you >> in my previous fixes before, and nobody before recommended me to >> follow this style with extra space in class cast expressions. Also I >> did not see this style was widely used in AWT code, except for the >> class "WToolkit", where I see many examples of it for the first time. >> Personally I do not like this extra space, but, if you insist and >> just for the purpose of making formatting style of this fix comply >> with other code only in "WTookit.java" file, I could add these extra >> spaces before pushing the fix, if the fix is approved by Sergey >> Bylokhov. >> >> Thank you, >> Anton >> >> On 20/04/2018 10:46, Alexey Ivanov wrote: >>> Hi Anton, >>> >>> The fix looks good. >>> >>> Could you please add space after the cast operator before pushing? >>> No additional review is required for this small code style change, I >>> believe. >>> >>> Regards, >>> Alexey >>> >>> On 19/04/2018 12:12, Anton Litvinov wrote: >>>> Hello Alexey, >>>> >>>> Thank you for review of this fix and for identification of this >>>> issue. Yes, I agree that the touch keyboard should not be hidden, >>>> when a focus is moved from one text component to the second, after >>>> the TAB key was pressed on the touch keyboard. Hiding it in this >>>> scenario, while not hiding the touch keyboard after touching the >>>> area of the second text component, is inconsistent. >>>> >>>> The new version of the fix addressing your remark was created. >>>> >>>> Webrev (the 2nd version): >>>> http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.01 >>>> >>>> This issue and the original bug is resolved in the 2nd version of >>>> the fix by not calling "WToolkit.hideTouchKeyboard()" on >>>> "FocusEvent.FOCUS_LOST" event, if a component which gets focus is a >>>> text component. Also this version of the fix contains resolution of >>>> a possible memory leak from the variables: "compOnTouchDownEvent", >>>> "compOnMousePressedEvent" by changing their types to >>>> "WeakReference" and contains small refactoring of "if" >>>> expressions in "WToolkit.showOrHideTouchKeyboard(Component, >>>> AWTEvent)" method. Could you please look at the 2nd version of the >>>> fix. >>>> >>>> Thank you, >>>> Anton >>>> >>>> On 17/04/2018 17:24, Alexey Ivanov wrote: >>>>> Hi Anton, >>>>> >>>>> Shouldn't touch keyboard remain visible if Tab key on the touch >>>>> keyboard itself is pressed? Provided the next focusable component >>>>> is a text component, of course. >>>>> >>>>> Consider the following scenario: start Notepad and open Replace >>>>> dialog. Touch "Find what" field: the touch keyboard appears. Press >>>>> Tab on the touch keyboard: the focus moves to "Replace with" field >>>>> and touch keyboard stays visible. >>>>> >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> On 16/04/2018 13:03, Anton Litvinov wrote: >>>>>> Hello, >>>>>> >>>>>> Could you please review the following fix for the bug. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199748 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.00 >>>>>> >>>>>> In the fix for JDK-8166772 it was deliberately implemented that >>>>>> the touch keyboard is shown only on "MouseEvent.MOUSE_RELEASED" >>>>>> event and is hidden on "FocusEvent.FOCUS_LOST" event. >>>>>> >>>>>> The reason of the bug is the fact that, when the touch keyboard >>>>>> is already shown for one text component and a user touches >>>>>> another text component, then the following 2 events occur in the >>>>>> presented order: >>>>>> 1. "MouseEvent.MOUSE_RELEASED" event arrives. The touch keyboard >>>>>> is shown for the new text component. >>>>>> 2. "FocusEvent.FOCUS_LOST" event arrives for the previous text >>>>>> component. The touch keyboard shown for the new text component >>>>>> becomes hidden. >>>>>> >>>>>> The fix allows not to hide the touch keyboard during processing >>>>>> of "FocusEvent.FOCUS_LOST" event, if the touch keyboard has just >>>>>> been shown, as a result of processing of >>>>>> "MouseEvent.MOUSE_RELEASED" event, for the component which gets >>>>>> focus "FocusEvent.getOppositeComponent()". >>>>>> >>>>>> Thank you, >>>>>> Anton >>>>> >>>> >>> >> > From dmitry.markov at oracle.com Mon Apr 23 15:23:38 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Mon, 23 Apr 2018 16:23:38 +0100 Subject: [11] RFR 8202143: Parts of 8193435 added in merge change set Message-ID: <931F011D-9C38-49E9-BD36-42E1ABAC63DD@oracle.com> Hello, Could you review a trivial fix for jdk11, please? bug: https://bugs.openjdk.java.net/browse/JDK-8202143 webrev: http://cr.openjdk.java.net/~dmarkov/8202143/webrev.00/ The text, which was removed by 8193435 [1], was accidentally added back via merge. The text related to pre-1.2 SecurityManager should be removed. Thanks, Dmitry [1] - https://bugs.openjdk.java.net/browse/JDK-8193435 -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Apr 23 17:21:52 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 23 Apr 2018 10:21:52 -0700 Subject: [11] RFR 8202143: Parts of 8193435 added in merge change set In-Reply-To: <931F011D-9C38-49E9-BD36-42E1ABAC63DD@oracle.com> References: <931F011D-9C38-49E9-BD36-42E1ABAC63DD@oracle.com> Message-ID: <6448d3e4-6337-fa4a-38ea-94e9e2f0fcc3@oracle.com> Looks fine. The merge was presumably a sync of 10 changes into 11. -phil. On 04/23/2018 08:23 AM, Dmitry Markov wrote: > Hello, > > Could you review a trivial fix for jdk11, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8202143 > webrev: http://cr.openjdk.java.net/~dmarkov/8202143/webrev.00/ > > > The text, which was removed by 8193435 [1], was accidentally added > back via merge. The text related to pre-1.2 SecurityManager should be > removed. > > Thanks, > Dmitry > > [1] - https://bugs.openjdk.java.net/browse/JDK-8193435 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Apr 23 23:46:56 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Apr 2018 16:46:56 -0700 Subject: [11] RFR 8202143: Parts of 8193435 added in merge change set In-Reply-To: <931F011D-9C38-49E9-BD36-42E1ABAC63DD@oracle.com> References: <931F011D-9C38-49E9-BD36-42E1ABAC63DD@oracle.com> Message-ID: <172cd855-5875-b8fe-2712-ccd674d8d59b@oracle.com> +1 On 23/04/2018 08:23, Dmitry Markov wrote: > Hello, > > Could you review a trivial fix for jdk11, please? > > ?bug: https://bugs.openjdk.java.net/browse/JDK-8202143 > ?webrev: http://cr.openjdk.java.net/~dmarkov/8202143/webrev.00/ > > The text, which was removed by 8193435 [1], was accidentally added back > via merge. The text related to pre-1.2 SecurityManager should be removed. > > Thanks, > Dmitry > > [1] - https://bugs.openjdk.java.net/browse/JDK-8193435 > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Apr 23 23:52:10 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Apr 2018 16:52:10 -0700 Subject: [11] Review request for 8199748: Touch keyboard is not shown, if text component gets focus from other text component In-Reply-To: <6cffd13d-e61c-1ce6-bcce-d9f3d74a2873@oracle.com> References: <2e0c6d5f-2e4d-5f8c-6737-729301e7f44c@oracle.com> <6cffd13d-e61c-1ce6-bcce-d9f3d74a2873@oracle.com> Message-ID: <600820a9-1e1c-6c16-8882-30adedc7de47@oracle.com> Looks fine. On 18/04/2018 11:47, Anton Litvinov wrote: > Hello Sergey, > > Thank you for review of this fix. No, this topic was not earlier > discussed in review process of fixes for other bugs on the touch > keyboard subject. We deliberately do not show the touch keyboard on > "FocusEvent.FOCUS_GAINED" event, because of the following reasons: > > 1.? This is the behavior observable in other native applications like MS > Edge browser, "notepad.exe", "explorer.exe" (File Explorer), Firefox > browser. In this applications the touch keyboard is not shown when the > text component just gets focus, the touch keyboard is shown after an > explicit touch action. > > 2.? Such behavior is implemented by some classes from .NET Framework and > is described on the following web page from Microsoft documentation. > Web page URL: > https://docs.microsoft.com/en-us/windows/uwp/design/input/keyboard-interactions#appendix > > > This passage from this web page describes such behavior: > "If your app sets focus programmatically to a text input control, the > touch keyboard is not invoked. This eliminates unexpected behaviors not > instigated directly by the user. However, the keyboard does > automatically hide when focus is moved programmatically to a non-text > input control." > > 3.? Showing the touch keyboard on "FocusEvent.FOCUS_GAINED" event may > lead us to the error in the following scenario: > Step 1 - A user touches a text component. > Step 2 - ? The text component receives focus. > Step 3 -???? The touch keyboard is shown. > Step 4 -? ???? The user manually closes the touch keyboard. > Step 5 - ?????? The user touches the text component again. > Step 6 - ???????? The touch keyboard is not shown, because the focus did > not leave the text component and no FOCUS_GAINED was received. > > Thank you for the suggestion to make "WTookit.compOnxxx" variables as > weak references, what should resolve the possible memory leak. I created > the new version of the fix for this bug, which includes the changes > listed below. Could you please look at the second version of the fix for > this bug. > > Webrev (the 2nd version): > http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.01 > > The 2nd version of the fix resolves the bug in absolutely different way > in comparison with the 1st version of the fix and has the following > changes: > 1)? The variables "WToolkit.compOnTouchDownEvent", > "WToolkit.compOnMousePressedEvent" were made instances of > "WeakReference". > 2)? The variable "NULL_COMPONENT_WR" was introduced to address issue > with thread safety with "compOnTouchDownEvent", > "compOnMousePressedEvent" variables. > 3)? The big "if" expression, which verifies if the component is valid > for showing the touch keyboard, was moved into a dedicated method > "boolean isComponentValidForTouchKeyboard(Component)". > 4)? Checks on equality to "null" were removed from the following "if" > expression, because further "instanceof" expressions for both "comp" and > "e" variables will also return "false", if these variables equal "null". > > "1103???????? if ((comp == null) || (e == null)" > > 5)? The bug itself is resolved by just not hiding the touch keyboard on > "FOCUS_LOST", if it is known that the component which gets focus is a > text component. This change of the fix addresses the issue described by > Alexey Ivanov in a parallel e-mail in the review of this fix, where with > the 1st version of the fix the touch keyboard would be hidden, if the > focus was shifted to the second text component by pressing "TAB" on the > touch keyboard. > > Thank you, > Anton > > On 17/04/2018 00:48, Sergey Bylokhov wrote: >> Hi, Anton. >> Maybe this was discussed before, but can you please clarify why we did >> not show the keyborad on focus_gain? >> >> BTW looks like the WTookit.compOnxxx should be a weak references. >> >> On 16/04/2018 05:03, Anton Litvinov wrote: >>> Hello, >>> >>> Could you please review the following fix for the bug. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199748 >>> Webrev: http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.00 >>> >>> In the fix for JDK-8166772 it was deliberately implemented that the >>> touch keyboard is shown only on "MouseEvent.MOUSE_RELEASED" event and >>> is hidden on "FocusEvent.FOCUS_LOST" event. >>> >>> The reason of the bug is the fact that, when the touch keyboard is >>> already shown for one text component and a user touches another text >>> component, then the following 2 events occur in the presented order: >>> 1. "MouseEvent.MOUSE_RELEASED" event arrives. The touch keyboard is >>> shown for the new text component. >>> 2. "FocusEvent.FOCUS_LOST" event arrives for the previous text >>> component. The touch keyboard shown for the new text component >>> becomes hidden. >>> >>> The fix allows not to hide the touch keyboard during processing of >>> "FocusEvent.FOCUS_LOST" event, if the touch keyboard has just been >>> shown, as a result of processing of "MouseEvent.MOUSE_RELEASED" >>> event, for the component which gets focus >>> "FocusEvent.getOppositeComponent()". >>> >>> Thank you, >>> Anton >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Apr 23 23:59:41 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Apr 2018 16:59:41 -0700 Subject: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. In-Reply-To: <6e9d1552-d256-4f79-bb07-5b55756d64e1@default> References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default> <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default> <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com> <992a8202-6ac9-4c16-9fe5-c316e314bed5@default> <814c85c6-0d8d-468c-a2af-fefa79e59ef7@default> <66fcf064-b200-4d6d-ac06-b78517074f00@default> <9fd92bf5-113c-782c-92e9-7b061ace2a6c@oracle.com> <27586cbb-be2c-4941-ade4-8493b501542b@default> <410e40d6-e7d7-4b2d-8647-2dbeb8b82c18@default> <4f0dbe63-e640-8183-b136-08da1af3c5cf@oracle.com> <948a2586-88e3-47cf-bf0f-84995eac96da@default> <80c936e4-fd72-437b-970a-4a71117e24f9@default> <636d9ff1-b9ef-4a9e-9a65-b0892e9bfa6b@default> <6e9d1552-d256-4f79-bb07-5b55756d64e1@default> Message-ID: <0790a618-16c6-c64e-3dd5-321ff2483730@oracle.com> Hi, Shashi. On 18/04/2018 23:52, Shashidhara Veerabhadraiah wrote: > Hi Sergey, I checked with Prashanth on the external input method. It is just same as change the locale and start input the characters in that locale. Once we change the locale it will try to install sogu or other stuffs to get those locale keys. But on the windows 10 it does not install anything but keyboard language is changed and we can start input those characters. So when I checked with input of different locale keys and found that most of them do generate the keyTyped/keyPressed/keyReleased events for the java component which is same as my implementation under this bug. Only for the Chinese input we only get the keyTyped event. I think since we provide the superset I think this problem is solved. So I think my current changes are fine so please let me know if you have any comments on it. I assume that you checked the steps above without the changes in files(AWTView.m/awt_Component.cpp/ etc). So external InputMethods(including Chinese input) works in java applications as-is. And it should work for windows/linux/macos. Why we need to change these files (AWTView.m/awt_Component.cpp/etc) instead of generate the same events, as input methods, using Robot API? -- Best regards, Sergey. From shashidhara.veerabhadraiah at oracle.com Tue Apr 24 04:28:02 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 23 Apr 2018 21:28:02 -0700 (PDT) Subject: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. In-Reply-To: <0790a618-16c6-c64e-3dd5-321ff2483730@oracle.com> References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default> <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default> <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com> <992a8202-6ac9-4c16-9fe5-c316e314bed5@default> <814c85c6-0d8d-468c-a2af-fefa79e59ef7@default> <66fcf064-b200-4d6d-ac06-b78517074f00@default> <9fd92bf5-113c-782c-92e9-7b061ace2a6c@oracle.com> <27586cbb-be2c-4941-ade4-8493b501542b@default> <410e40d6-e7d7-4b2d-8647-2dbeb8b82c18@default> <4f0dbe63-e640-8183-b136-08da1af3c5cf@oracle.com> <948a2586-88e3-47cf-bf0f-84995eac96da@default> <80c936e4-fd72-437b-970a-4a71117e24f9@default> <636d9ff1-b9ef-4a9e-9a65-b0892e9bfa6b@default> <6e9d1552-d256-4f79-bb07-5b55756d64e1@default> <0790a618-16c6-c64e-3dd5-321ff2483730@oracle.com> Message-ID: Hi Sergey, Thanks for your time in reviewing this. Below are my answers: Thanks and regards, Shashi -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, April 24, 2018 5:30 AM To: Shashidhara Veerabhadraiah ; awt-dev at openjdk.java.net Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. Hi, Shashi. On 18/04/2018 23:52, Shashidhara Veerabhadraiah wrote: > Hi Sergey, I checked with Prashanth on the external input method. It is just same as change the locale and start input the characters in that locale. Once we change the locale it will try to install sogu or other stuffs to get those locale keys. But on the windows 10 it does not install anything but keyboard language is changed and we can start input those characters. So when I checked with input of different locale keys and found that most of them do generate the keyTyped/keyPressed/keyReleased events for the java component which is same as my implementation under this bug. Only for the Chinese input we only get the keyTyped event. I think since we provide the superset I think this problem is solved. So I think my current changes are fine so please let me know if you have any comments on it. I assume that you checked the steps above without the changes in files(AWTView.m/awt_Component.cpp/ etc). So external InputMethods(including Chinese input) works in java applications as-is. And it should work for windows/linux/macos. Why we need to change these files (AWTView.m/awt_Component.cpp/etc) instead of generate the same events, as input methods, using Robot API? [Shashi] Yes it was checked without my changes in. Robot key events is a different method of input compared to the external input method. Robot Unicode key input api uses the Unicode code point as input and our keyboard language remains same. So for ex., keyboard language is set to US and if we want to input Russian language(Cyrillic U+0400 onwards) into a component, we can use the newly formed Unicode input api. Otherwise in the case of external input method, we would need to change the keyboard language to Russian and then input only Russian keys using the physical keys and switch back to US keyboard style to input the US symbols. The later way is not required to be done by the current robot Unicode implementation. Hence with this implementation the user can simply say as "keyUnicode(1024)"(U+0400) without changing the keyboard language. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Apr 24 05:22:03 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Apr 2018 22:22:03 -0700 Subject: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. In-Reply-To: References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default> <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default> <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com> <992a8202-6ac9-4c16-9fe5-c316e314bed5@default> <814c85c6-0d8d-468c-a2af-fefa79e59ef7@default> <66fcf064-b200-4d6d-ac06-b78517074f00@default> <9fd92bf5-113c-782c-92e9-7b061ace2a6c@oracle.com> <27586cbb-be2c-4941-ade4-8493b501542b@default> <410e40d6-e7d7-4b2d-8647-2dbeb8b82c18@default> <4f0dbe63-e640-8183-b136-08da1af3c5cf@oracle.com> <948a2586-88e3-47cf-bf0f-84995eac96da@default> <80c936e4-fd72-437b-970a-4a71117e24f9@default> <636d9ff1-b9ef-4a9e-9a65-b0892e9bfa6b@default> <6e9d1552-d256-4f79-bb07-5b55756d64e1@default> <0790a618-16c6-c64e-3dd5-321ff2483730@oracle.com> Message-ID: <09647cdc-c5f6-052d-4585-c0c072bc969d@oracle.com> On 23/04/2018 21:28, Shashidhara Veerabhadraiah wrote: > [Shashi] Yes it was checked without my changes in. Robot key events is a different method of input compared to the external input method. Robot Unicode key input api uses the Unicode code point as input and our keyboard language remains same. So for ex., keyboard language is set to US and if we want to input Russian language(Cyrillic U+0400 onwards) into a component, we can use the newly formed Unicode input api. Otherwise in the case of external input method, we would need to change the keyboard language to Russian and then input only Russian keys using the physical keys and switch back to US keyboard style to input the US symbols. The later way is not required to be done by the current robot Unicode implementation. Hence with this implementation the user can simply say as "keyUnicode(1024)"(U+0400) without changing the keyboard language. You describe two different cases: - If you generate an event for some char like '?' in the current locale and can obtain which keyCode is assigned to this char, then it is the same as generate event for this keyCode. In this case the changes in classes other than Robot are not necessary. - If you generate an event for some char like '?' in some other(not currently used locale) and cannot obtain which keyCode is assigned to this char, then it is the same as generate "type" event for Chinese char. In this case the changes in classes other than Robot are not necessary, because it should work in the current java apps(On macOS this character "?" may be generated by "alt+a" in US locale). From shashidhara.veerabhadraiah at oracle.com Tue Apr 24 06:03:15 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Mon, 23 Apr 2018 23:03:15 -0700 (PDT) Subject: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. In-Reply-To: <09647cdc-c5f6-052d-4585-c0c072bc969d@oracle.com> References: <8ddfdf09-9752-4193-ba8b-6a3f4db5f42d@default> <6ceef8cc-c8d2-4ea6-a618-c39cb5c6ba75@default> <2e38b120-cf62-f2a1-1374-1449f9556a18@oracle.com> <992a8202-6ac9-4c16-9fe5-c316e314bed5@default> <814c85c6-0d8d-468c-a2af-fefa79e59ef7@default> <66fcf064-b200-4d6d-ac06-b78517074f00@default> <9fd92bf5-113c-782c-92e9-7b061ace2a6c@oracle.com> <27586cbb-be2c-4941-ade4-8493b501542b@default> <410e40d6-e7d7-4b2d-8647-2dbeb8b82c18@default> <4f0dbe63-e640-8183-b136-08da1af3c5cf@oracle.com> <948a2586-88e3-47cf-bf0f-84995eac96da@default> <80c936e4-fd72-437b-970a-4a71117e24f9@default> <636d9ff1-b9ef-4a9e-9a65-b0892e9bfa6b@default> <6e9d1552-d256-4f79-bb07-5b55756d64e1@default> <0790a618-16c6-c64e-3dd5-321ff2483730@oracle.com> <09647cdc-c5f6-052d-4585-c0c072bc969d@oracle.com> Message-ID: Hi Sergey, So if a user wants to input Unicode U+00E5(alt + a in mac but it's not the same as in windows), user should say that "keyUnicode(229)". Without using this, user can input the same via the keyPress(alt)+keyPress(a) assuming locale is en_US and this works only for the mac and it may require different key combinations on different platforms and it may work only for a subset of the entire Unicode set because of the limited number of hardware keys. Moreover system locale being common shared setting across system, changing it internally is not advisable because other java application may need to set it to a different locale via core java api's. Hence there is only way to input the unicode keys i.e., via the new api keyUnicode(Unicode point). I assume you agree to this. Please comment if you disagree to this. Assuming to agree to above, keyCode in KeyEvent refers to the virtual key codes as defined in their respective platform implementation. Since my change brings in the Unicode key input we don't need to set the keyCode but a new field unicodeKey which would contain the respective Unicode key that was input at the start. This brings an entire new sequence of change which does not impact in any way with the existing keyPress()/keyRelease() mechanism. Hope am clear here or we can discuss this over the coming Wednesday call. Please correct me if I am wrong anywhere here. Thanks and regards, Shashi -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, April 24, 2018 10:52 AM To: Shashidhara Veerabhadraiah ; awt-dev at openjdk.java.net Subject: Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?. On 23/04/2018 21:28, Shashidhara Veerabhadraiah wrote: > [Shashi] Yes it was checked without my changes in. Robot key events is a different method of input compared to the external input method. Robot Unicode key input api uses the Unicode code point as input and our keyboard language remains same. So for ex., keyboard language is set to US and if we want to input Russian language(Cyrillic U+0400 onwards) into a component, we can use the newly formed Unicode input api. Otherwise in the case of external input method, we would need to change the keyboard language to Russian and then input only Russian keys using the physical keys and switch back to US keyboard style to input the US symbols. The later way is not required to be done by the current robot Unicode implementation. Hence with this implementation the user can simply say as "keyUnicode(1024)"(U+0400) without changing the keyboard language. You describe two different cases: - If you generate an event for some char like '?' in the current locale and can obtain which keyCode is assigned to this char, then it is the same as generate event for this keyCode. In this case the changes in classes other than Robot are not necessary. - If you generate an event for some char like '?' in some other(not currently used locale) and cannot obtain which keyCode is assigned to this char, then it is the same as generate "type" event for Chinese char. In this case the changes in classes other than Robot are not necessary, because it should work in the current java apps(On macOS this character "?" may be generated by "alt+a" in US locale). From alexey.ivanov at oracle.com Tue Apr 24 12:53:53 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 24 Apr 2018 13:53:53 +0100 Subject: [11] Review request for 8199748: Touch keyboard is not shown, if text component gets focus from other text component In-Reply-To: References: <019c5cd2-367d-6c26-aa88-69cb5c68c217@oracle.com> <3c04a4d9-001f-abf3-0501-a87fc8decbba@oracle.com> <98b3163f-4a7f-87a5-4c16-37ccc953b6dc@oracle.com> <0bc93c7f-fcb2-e6f0-9ffe-9bfb8cc08666@oracle.com> <29c90708-a97d-5bf9-9d80-3f88078e6ef6@oracle.com> Message-ID: <18bcbab3-5174-ec48-175d-d84ff8a4b6f1@oracle.com> Hi Anton, On 23/04/2018 16:20, Anton Litvinov wrote: > Hi Alexey, > > Since you insist so much on adding this space character, No, I don't insist. I'm fine with either style. It's up to you to choose the style: either with space or without it. Regards, Alexey > I am doing this, however, I think that absence of this space character > would not influence readability, is purely a matter of personal > preference and habits of the programmer. The 3rd version of the fix, > which is identical to the 2nd version with the exception of added 4 > spaces in 4 places listed below, was created. > > Webrev (the 3rd version): > http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.02 > > Source code lines, where this space character was introduced: > - 1109???????????? ((TextComponent) comp).isEditable()) || > - 1111???????????? ((JTextComponent) comp).isEditable()))) { > - 1125???????????? MouseEvent me = (MouseEvent) e; > - 1146???????????? FocusEvent fe = (FocusEvent) e; > > Regards, > Anton > > On 20/04/2018 19:16, Alexey Ivanov wrote: >> Hi Anton, >> >> I implied the space after the cast would be added in all the cases >> where cast is used in this code. >> >> I don't insist: both styles are used throughout AWT and Swing; even >> in WToolkit.java both are used. >> >> I'm not for strictly following guidelines but for consistency. The >> closest functions with casts to your code are grab() and ungrab(). In >> both cases, there's a space after cast. Sergey Bylokhov has added the >> space as part of JDK-8074028 [1][2]. >> >> However, Code Conventions for the Java? Programming Language [3] >> recommends using space after cast. >> >> Regards, >> Alexey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8074028 >> [2] http://hg.openjdk.java.net/jdk9/client/jdk/rev/39bd7fa12bc3#l83.35 >> [3] >> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#682 >> >> On 20/04/2018 14:30, Anton Litvinov wrote: >>> Hello Alexey, >>> >>> Thank you for approval of the 2nd version of the fix. I understand >>> your recommendation to add space character in class cast >>> expressions, for example to make the expression >>> >>> ??? 1109 ((TextComponent)comp).isEditable()) || >>> >>> look as >>> >>> ??? 1109???????????????????? ((TextComponent) comp).isEditable()) || >>> >>> But in case of this fix it will be necessary to apply this change to >>> other code related to the fix, like: >>> >>> ??? 1125???????????? MouseEvent me = (MouseEvent)e; >>> ??? 1146???????????? FocusEvent fe = (FocusEvent)e; >>> >>> In fact, I have never used the style of formatting suggested by you >>> in my previous fixes before, and nobody before recommended me to >>> follow this style with extra space in class cast expressions. Also I >>> did not see this style was widely used in AWT code, except for the >>> class "WToolkit", where I see many examples of it for the first >>> time. Personally I do not like this extra space, but, if you insist >>> and just for the purpose of making formatting style of this fix >>> comply with other code only in "WTookit.java" file, I could add >>> these extra spaces before pushing the fix, if the fix is approved by >>> Sergey Bylokhov. >>> >>> Thank you, >>> Anton >>> >>> On 20/04/2018 10:46, Alexey Ivanov wrote: >>>> Hi Anton, >>>> >>>> The fix looks good. >>>> >>>> Could you please add space after the cast operator before pushing? >>>> No additional review is required for this small code style change, >>>> I believe. >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 19/04/2018 12:12, Anton Litvinov wrote: >>>>> Hello Alexey, >>>>> >>>>> Thank you for review of this fix and for identification of this >>>>> issue. Yes, I agree that the touch keyboard should not be hidden, >>>>> when a focus is moved from one text component to the second, after >>>>> the TAB key was pressed on the touch keyboard. Hiding it in this >>>>> scenario, while not hiding the touch keyboard after touching the >>>>> area of the second text component, is inconsistent. >>>>> >>>>> The new version of the fix addressing your remark was created. >>>>> >>>>> Webrev (the 2nd version): >>>>> http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.01 >>>>> >>>>> This issue and the original bug is resolved in the 2nd version of >>>>> the fix by not calling "WToolkit.hideTouchKeyboard()" on >>>>> "FocusEvent.FOCUS_LOST" event, if a component which gets focus is >>>>> a text component. Also this version of the fix contains resolution >>>>> of a possible memory leak from the variables: >>>>> "compOnTouchDownEvent", "compOnMousePressedEvent" by changing >>>>> their types to "WeakReference" and contains small >>>>> refactoring of "if" expressions in >>>>> "WToolkit.showOrHideTouchKeyboard(Component, AWTEvent)" method. >>>>> Could you please look at the 2nd version of the fix. >>>>> >>>>> Thank you, >>>>> Anton >>>>> >>>>> On 17/04/2018 17:24, Alexey Ivanov wrote: >>>>>> Hi Anton, >>>>>> >>>>>> Shouldn't touch keyboard remain visible if Tab key on the touch >>>>>> keyboard itself is pressed? Provided the next focusable component >>>>>> is a text component, of course. >>>>>> >>>>>> Consider the following scenario: start Notepad and open Replace >>>>>> dialog. Touch "Find what" field: the touch keyboard appears. >>>>>> Press Tab on the touch keyboard: the focus moves to "Replace >>>>>> with" field and touch keyboard stays visible. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> On 16/04/2018 13:03, Anton Litvinov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you please review the following fix for the bug. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199748 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.00 >>>>>>> >>>>>>> In the fix for JDK-8166772 it was deliberately implemented that >>>>>>> the touch keyboard is shown only on "MouseEvent.MOUSE_RELEASED" >>>>>>> event and is hidden on "FocusEvent.FOCUS_LOST" event. >>>>>>> >>>>>>> The reason of the bug is the fact that, when the touch keyboard >>>>>>> is already shown for one text component and a user touches >>>>>>> another text component, then the following 2 events occur in the >>>>>>> presented order: >>>>>>> 1. "MouseEvent.MOUSE_RELEASED" event arrives. The touch keyboard >>>>>>> is shown for the new text component. >>>>>>> 2. "FocusEvent.FOCUS_LOST" event arrives for the previous text >>>>>>> component. The touch keyboard shown for the new text component >>>>>>> becomes hidden. >>>>>>> >>>>>>> The fix allows not to hide the touch keyboard during processing >>>>>>> of "FocusEvent.FOCUS_LOST" event, if the touch keyboard has just >>>>>>> been shown, as a result of processing of >>>>>>> "MouseEvent.MOUSE_RELEASED" event, for the component which gets >>>>>>> focus "FocusEvent.getOppositeComponent()". >>>>>>> >>>>>>> Thank you, >>>>>>> Anton >>>>>> >>>>> >>>> >>> >> > From anton.litvinov at oracle.com Tue Apr 24 13:52:17 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Tue, 24 Apr 2018 14:52:17 +0100 Subject: [11] Review request for 8199748: Touch keyboard is not shown, if text component gets focus from other text component In-Reply-To: <18bcbab3-5174-ec48-175d-d84ff8a4b6f1@oracle.com> References: <019c5cd2-367d-6c26-aa88-69cb5c68c217@oracle.com> <3c04a4d9-001f-abf3-0501-a87fc8decbba@oracle.com> <98b3163f-4a7f-87a5-4c16-37ccc953b6dc@oracle.com> <0bc93c7f-fcb2-e6f0-9ffe-9bfb8cc08666@oracle.com> <29c90708-a97d-5bf9-9d80-3f88078e6ef6@oracle.com> <18bcbab3-5174-ec48-175d-d84ff8a4b6f1@oracle.com> Message-ID: Hi Alexey, Good, thank you, I understood. I will push the 3rd version of the fix with spaces. Thank you, Anton On 24/04/2018 13:53, Alexey Ivanov wrote: > Hi Anton, > > On 23/04/2018 16:20, Anton Litvinov wrote: >> Hi Alexey, >> >> Since you insist so much on adding this space character, > > No, I don't insist. I'm fine with either style. > It's up to you to choose the style: either with space or without it. > > > Regards, > Alexey > >> I am doing this, however, I think that absence of this space >> character would not influence readability, is purely a matter of >> personal preference and habits of the programmer. The 3rd version of >> the fix, which is identical to the 2nd version with the exception of >> added 4 spaces in 4 places listed below, was created. >> >> Webrev (the 3rd version): >> http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.02 >> >> Source code lines, where this space character was introduced: >> - 1109???????????? ((TextComponent) comp).isEditable()) || >> - 1111???????????? ((JTextComponent) comp).isEditable()))) { >> - 1125???????????? MouseEvent me = (MouseEvent) e; >> - 1146???????????? FocusEvent fe = (FocusEvent) e; >> >> Regards, >> Anton >> >> On 20/04/2018 19:16, Alexey Ivanov wrote: >>> Hi Anton, >>> >>> I implied the space after the cast would be added in all the cases >>> where cast is used in this code. >>> >>> I don't insist: both styles are used throughout AWT and Swing; even >>> in WToolkit.java both are used. >>> >>> I'm not for strictly following guidelines but for consistency. The >>> closest functions with casts to your code are grab() and ungrab(). >>> In both cases, there's a space after cast. Sergey Bylokhov has added >>> the space as part of JDK-8074028 [1][2]. >>> >>> However, Code Conventions for the Java? Programming Language [3] >>> recommends using space after cast. >>> >>> Regards, >>> Alexey >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8074028 >>> [2] http://hg.openjdk.java.net/jdk9/client/jdk/rev/39bd7fa12bc3#l83.35 >>> [3] >>> http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#682 >>> >>> On 20/04/2018 14:30, Anton Litvinov wrote: >>>> Hello Alexey, >>>> >>>> Thank you for approval of the 2nd version of the fix. I understand >>>> your recommendation to add space character in class cast >>>> expressions, for example to make the expression >>>> >>>> ??? 1109 ((TextComponent)comp).isEditable()) || >>>> >>>> look as >>>> >>>> ??? 1109???????????????????? ((TextComponent) comp).isEditable()) || >>>> >>>> But in case of this fix it will be necessary to apply this change >>>> to other code related to the fix, like: >>>> >>>> ??? 1125???????????? MouseEvent me = (MouseEvent)e; >>>> ??? 1146???????????? FocusEvent fe = (FocusEvent)e; >>>> >>>> In fact, I have never used the style of formatting suggested by you >>>> in my previous fixes before, and nobody before recommended me to >>>> follow this style with extra space in class cast expressions. Also >>>> I did not see this style was widely used in AWT code, except for >>>> the class "WToolkit", where I see many examples of it for the first >>>> time. Personally I do not like this extra space, but, if you insist >>>> and just for the purpose of making formatting style of this fix >>>> comply with other code only in "WTookit.java" file, I could add >>>> these extra spaces before pushing the fix, if the fix is approved >>>> by Sergey Bylokhov. >>>> >>>> Thank you, >>>> Anton >>>> >>>> On 20/04/2018 10:46, Alexey Ivanov wrote: >>>>> Hi Anton, >>>>> >>>>> The fix looks good. >>>>> >>>>> Could you please add space after the cast operator before pushing? >>>>> No additional review is required for this small code style change, >>>>> I believe. >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> On 19/04/2018 12:12, Anton Litvinov wrote: >>>>>> Hello Alexey, >>>>>> >>>>>> Thank you for review of this fix and for identification of this >>>>>> issue. Yes, I agree that the touch keyboard should not be hidden, >>>>>> when a focus is moved from one text component to the second, >>>>>> after the TAB key was pressed on the touch keyboard. Hiding it in >>>>>> this scenario, while not hiding the touch keyboard after touching >>>>>> the area of the second text component, is inconsistent. >>>>>> >>>>>> The new version of the fix addressing your remark was created. >>>>>> >>>>>> Webrev (the 2nd version): >>>>>> http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.01 >>>>>> >>>>>> This issue and the original bug is resolved in the 2nd version of >>>>>> the fix by not calling "WToolkit.hideTouchKeyboard()" on >>>>>> "FocusEvent.FOCUS_LOST" event, if a component which gets focus is >>>>>> a text component. Also this version of the fix contains >>>>>> resolution of a possible memory leak from the variables: >>>>>> "compOnTouchDownEvent", "compOnMousePressedEvent" by changing >>>>>> their types to "WeakReference" and contains small >>>>>> refactoring of "if" expressions in >>>>>> "WToolkit.showOrHideTouchKeyboard(Component, AWTEvent)" method. >>>>>> Could you please look at the 2nd version of the fix. >>>>>> >>>>>> Thank you, >>>>>> Anton >>>>>> >>>>>> On 17/04/2018 17:24, Alexey Ivanov wrote: >>>>>>> Hi Anton, >>>>>>> >>>>>>> Shouldn't touch keyboard remain visible if Tab key on the touch >>>>>>> keyboard itself is pressed? Provided the next focusable >>>>>>> component is a text component, of course. >>>>>>> >>>>>>> Consider the following scenario: start Notepad and open Replace >>>>>>> dialog. Touch "Find what" field: the touch keyboard appears. >>>>>>> Press Tab on the touch keyboard: the focus moves to "Replace >>>>>>> with" field and touch keyboard stays visible. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>> On 16/04/2018 13:03, Anton Litvinov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you please review the following fix for the bug. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199748 >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~alitvinov/8199748/jdk11/webrev.00 >>>>>>>> >>>>>>>> In the fix for JDK-8166772 it was deliberately implemented that >>>>>>>> the touch keyboard is shown only on "MouseEvent.MOUSE_RELEASED" >>>>>>>> event and is hidden on "FocusEvent.FOCUS_LOST" event. >>>>>>>> >>>>>>>> The reason of the bug is the fact that, when the touch keyboard >>>>>>>> is already shown for one text component and a user touches >>>>>>>> another text component, then the following 2 events occur in >>>>>>>> the presented order: >>>>>>>> 1. "MouseEvent.MOUSE_RELEASED" event arrives. The touch >>>>>>>> keyboard is shown for the new text component. >>>>>>>> 2. "FocusEvent.FOCUS_LOST" event arrives for the previous text >>>>>>>> component. The touch keyboard shown for the new text component >>>>>>>> becomes hidden. >>>>>>>> >>>>>>>> The fix allows not to hide the touch keyboard during processing >>>>>>>> of "FocusEvent.FOCUS_LOST" event, if the touch keyboard has >>>>>>>> just been shown, as a result of processing of >>>>>>>> "MouseEvent.MOUSE_RELEASED" event, for the component which gets >>>>>>>> focus "FocusEvent.getOppositeComponent()". >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Anton >>>>>>> >>>>>> >>>>> >>>> >>> >> > From anton.tarasov at jetbrains.com Thu Apr 26 07:53:30 2018 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Thu, 26 Apr 2018 10:53:30 +0300 Subject: [11] Review request for 8202084: [win] IME candidate window wrong position In-Reply-To: <5c0669e6-bfd6-6a7f-0063-6370c3e8f7f0@jetbrains.com> References: <5c0669e6-bfd6-6a7f-0063-6370c3e8f7f0@jetbrains.com> Message-ID: <8b3d56fc-1954-de58-e4d2-134cdbf7e4df@jetbrains.com> Reviewed on swing-dev: http://mail.openjdk.java.net/pipermail/swing-dev/2018-April/008574.html On 4/20/2018 6:51 PM, Anton Tarasov wrote: > Hello! > > Could you please review the fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202084 > webrev: http://cr.openjdk.java.net/~ant/JDK-8202084/webrev.0 > > There are two problems: > 1) IME candidate window x/y is not scaled. > 2) The ancestor window for IME is not the current window when it's "a > simple window", but the focus proxy (the owner). > > Thanks, > Anton. From manajit.halder at oracle.com Fri Apr 27 10:36:58 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Fri, 27 Apr 2018 16:06:58 +0530 Subject: [11] Review request for JDK-8029250: [macosx] There is no tray icon shown in the system tray area when case starts Message-ID: <4919F580-0B5F-46D6-8528-A79E841E9103@oracle.com> Hi All, Kindly review the following AWT enhancement changes: Bug: https://bugs.openjdk.java.net/browse/JDK-8029250 Webrev: http://cr.openjdk.java.net/~mhalder/8029250/webrev.00/ Fix: Added support for gif images (image animation) for Mac system tray. Before fix only single frame was passed to Mac OS system tray on mouse click from the Java side. After fix all the frames are passed at the time interval set in the image one by one to the Mac OS side. Note: The test was moved from closed test to open test along with 3 images: ball.gif, spot.gif and duke.gif. The test code was rewritten dropping the applet code used earlier. Regards, Manajit -------------- next part -------------- An HTML attachment was scrubbed... URL: