From prasanta.sadhukhan at oracle.com Wed Apr 1 08:03:37 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 1 Apr 2020 13:33:37 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <5c8527be-d47f-7052-124d-361b21b26e49@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <5C9F6E0B-BBEE-458F-BF6F-0CFE6D0C5D35@oracle.com> <2b39d545-0f0c-d6da-cfc0-f989a071fe4d@oracle.com> <4E01B9E7-0142-4345-8644-9F62CAE212CC@oracle.com> <195430c6-8890-8933-9f13-0eda88bb684a@oracle.com> <4e294d89-d320-56cb-6178-8da5b7c8649e@oracle.com>

<2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>

<23ffdef1-4dd2-7820-a57d-d4f6410302bf@oracle.com> <8757e954-b413-a68f-a6d7-7b2fd66cb6e1@oracle.com> <260266da-9c2d-ebb8-6af0-58bcf6162e04@oracle.com> <5c8527be-d47f-7052-124d-361b21b26e49@oracle.com> Message-ID: <3e37c6d4-4ddb-a829-7504-b2afd92b6996@oracle.com> It is because of the same issue the size is not updated as ToolTipManager#showTipWindow() calls popupFactory.getPopup() before tip.show() and as per flow, getPopup() => getLightWeightPopup() => popup.reset() => pack() calls component.setSize(component.getPreferredSize()) where the preferredSize is not yet updated. Regards Prasanta On 01-Apr-20 5:11 AM, Sergey Bylokhov wrote: > That looks much better! The only question I have is why the size is > not updated - is it intentional behaviour or we can tweak it somehow. > > On 3/31/20 1:13 am, Prasanta Sadhukhan wrote: >> View is updated by calling BasicHTML.updateRenderer when >> "graphicsConfiguration" property is fired when tooltip is shown via >> tip.show() in ToolTipManager. Now, we should be using the updated >> preferredSize calculated by View.getPreferredSpan but >> BasicToolTip#paint still uses the old size. Proposed fix is to use >> the updated preferredSize. >> >> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.2/ >> >> Regards >> Prasanta >> On 28-Mar-20 8:49 AM, Sergey Bylokhov wrote: >>> On 3/27/20 3:27 am, Prasanta Sadhukhan wrote: >>>> >>>> On 07-Dec-19 10:28 AM, Sergey Bylokhov wrote: >>>>> On 12/6/19 7:24 pm, Prasanta Sadhukhan wrote: >>>>>>> How other components which may use HTML inside calculates its >>>>>>> preferred size? I do not remember that they additionally scale >>>>>>> the values returned by the View. >>>>>> >>>>>> Maybe those components does not use preferredSize calculation as >>>>>> JTooltip does. >>>>> >>>>> Even if it not used, the preferredSize of the components and views >>>>> should return correct values. >>>>> >>>>> >>>> getPreferredSize() is called from ToolTipManager but it is done >>>> *before *calling Tooltip.show() which actually triggers >>>> PropertyChangeEvent with "graphicsConfiguration" property. >>>> >>>> Now, View is updated by calling BasicHTML.updateRenderer() when >>>> "graphicsConfiguration" property is fired to notify transform is >>>> changed, so during preferredSize() call, the View has not yet been >>>> updated with correct transform. >>> >>> It means that the View should use GCOnfig of its parent-parent-etc, >>> which is default/main GC if the components/windows are invisible or >>> the GC of the real screen where the component/window is located. Or >>> the size of the tooltip should be revalidated at the moment we found >>> that the preferred size was calculated using the wrong GC. >>> >>> I think we should do both steps above. >>> >>> >>> Note that we should never calculate "coordinate_XY * scale" and >>> return this value to the user. The result of "coord*scale" should be >>> only used when we pass the data to the native code, in all other >>> places we should use just plain coordinates in the user's space. >>> >>>> So, my proposed fix is still same >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.1/ >>>> >>>> Regards >>>> Prasanta >>> >>> > > From alexey.ivanov at oracle.com Wed Apr 1 18:47:12 2020 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 1 Apr 2020 19:47:12 +0100 Subject: RFR: 8233584: [Win LAF] When navigating the contents of the file list changes in Win LAF In-Reply-To: <33cfebf6-2eac-ea58-781b-d8c0283cda4a@oracle.com> References: <60d5b758-df58-9ba7-04a4-1603fa205263@oracle.com> <33cfebf6-2eac-ea58-781b-d8c0283cda4a@oracle.com> Message-ID: <3e20ef5a-6549-0a8e-d017-fc71bff92de6@oracle.com> Hi Bhawesh, Shall we add @requires |os.family == "windows" to the test? Then it won't be even selected for running by jtreg. It think the copyright year should be updated in both modified files, should it? I'd also suggest using explicit import statements for javax.swing.* classes instead of the wildcard one. Is it possible to make the automatic? However, this is out of scope of this bug. Regards, Alexey | On 31/03/2020 10:16, Bhawesh Choudhary wrote: > Hi, > > Please find updated Webrev as per suggestions [Test case updates for > WindowsLookAndFeel] > > JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 > Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.1/ > > -Bhawesh > > On 3/13/2020 12:10 PM, Bhawesh Choudhary wrote: >> Hi, >> >> Please find updated Webrev as per suggestions [Test name update and >> Code formatting] >> >> JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 >> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.01/ >> >> -Bhawesh >> >> On 3/4/2020 4:13 PM, Bhawesh Choudhary wrote: >>> Hi, >>> >>> Please review this fix, >>> JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 >>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev/ >>> >>> Issue: >>> In Windows LookAndFeel, When navigating Combobox's list of >>> JFileChooser via keys, the contents of JFileChooser changes. >>> >>> Fix: >>> Set flag "JComboBox.isTableCellEditor" to True which prohibits >>> JCombobox from sending selection change event when JCombobox's list >>> selection change happens via keys. >>> >>> >>> Verification: >>> Tested the fix with JFileChooser with WindowsLookAndFeelEnabled as >>> well as BasicLookAndFeel with keys navigation. also added a test >>> case to verify the same. >>> >>> Did not find any misbehavior with the fix. >>> >>> Regards >>> Bhawesh From Sergey.Bylokhov at oracle.com Thu Apr 2 16:15:10 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 2 Apr 2020 09:15:10 -0700 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <3e37c6d4-4ddb-a829-7504-b2afd92b6996@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <5C9F6E0B-BBEE-458F-BF6F-0CFE6D0C5D35@oracle.com> <2b39d545-0f0c-d6da-cfc0-f989a071fe4d@oracle.com> <4E01B9E7-0142-4345-8644-9F62CAE212CC@oracle.com> <195430c6-8890-8933-9f13-0eda88bb684a@oracle.com> <4e294d89-d320-56cb-6178-8da5b7c8649e@oracle.com>

<2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>

<23ffdef1-4dd2-7820-a57d-d4f6410302bf@oracle.com> <8757e954-b413-a68f-a6d7-7b2fd66cb6e1@oracle.com> <260266da-9c2d-ebb8-6af0-58bcf6162e04@oracle.com> <5c8527be-d47f-7052-124d-361b21b26e49@oracle.com> <3e37c6d4-4ddb-a829-7504-b2afd92b6996@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> Message-ID: On 02-Apr-20 9:45 PM, Sergey Bylokhov wrote: > On 4/1/20 1:03 am, Prasanta Sadhukhan wrote: >> It is because of the same issue the size is not updated as >> ToolTipManager#showTipWindow() calls popupFactory.getPopup() before >> tip.show() and as per flow, >> >> getPopup() => getLightWeightPopup() => popup.reset() => pack() calls >> component.setSize(component.getPreferredSize()) where the >> preferredSize is not yet updated. > > It does not updated because it uses the wrong graphics configuration > and as a result the wrong font metrics? > Can we set correct GC as part of reset/pack steps for the popup? > As I told, the tip is not yet shown, so the graphicsConfiguration property is not yet fired so please appraise me how to set correct GC in reset/pack step? >> >> Regards >> Prasanta >> On 01-Apr-20 5:11 AM, Sergey Bylokhov wrote: >>> That looks much better! The only question I have is why the size is >>> not updated - is it intentional behaviour or we can tweak it somehow. >>> >>> On 3/31/20 1:13 am, Prasanta Sadhukhan wrote: >>>> View is updated by calling BasicHTML.updateRenderer when >>>> "graphicsConfiguration" property is fired when tooltip is shown via >>>> tip.show() in ToolTipManager. Now, we should be using the updated >>>> preferredSize calculated by View.getPreferredSpan but >>>> BasicToolTip#paint still uses the old size. Proposed fix is to use >>>> the updated preferredSize. >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.2/ >>>> >>>> Regards >>>> Prasanta >>>> On 28-Mar-20 8:49 AM, Sergey Bylokhov wrote: >>>>> On 3/27/20 3:27 am, Prasanta Sadhukhan wrote: >>>>>> >>>>>> On 07-Dec-19 10:28 AM, Sergey Bylokhov wrote: >>>>>>> On 12/6/19 7:24 pm, Prasanta Sadhukhan wrote: >>>>>>>>> How other components which may use HTML inside calculates its >>>>>>>>> preferred size? I do not remember that they additionally scale >>>>>>>>> the values returned by the View. >>>>>>>> >>>>>>>> Maybe those components does not use preferredSize calculation >>>>>>>> as JTooltip does. >>>>>>> >>>>>>> Even if it not used, the preferredSize of the components and >>>>>>> views should return correct values. >>>>>>> >>>>>>> >>>>>> getPreferredSize() is called from ToolTipManager but it is done >>>>>> *before *calling Tooltip.show() which actually triggers >>>>>> PropertyChangeEvent with "graphicsConfiguration" property. >>>>>> >>>>>> Now, View is updated by calling BasicHTML.updateRenderer() when >>>>>> "graphicsConfiguration" property is fired to notify transform is >>>>>> changed, so during preferredSize() call, the View has not yet >>>>>> been updated with correct transform. >>>>> >>>>> It means that the View should use GCOnfig of its >>>>> parent-parent-etc, which is default/main GC if the >>>>> components/windows are invisible or the GC of the real screen >>>>> where the component/window is located. Or the size of the tooltip >>>>> should be revalidated at the moment we found that the preferred >>>>> size was calculated using the wrong GC. >>>>> >>>>> I think we should do both steps above. >>>>> >>>>> >>>>> Note that we should never calculate "coordinate_XY * scale" and >>>>> return this value to the user. The result of "coord*scale" should >>>>> be only used when we pass the data to the native code, in all >>>>> other places we should use just plain coordinates in the user's >>>>> space. >>>>> >>>>>> So, my proposed fix is still same >>>>>> >>>>>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.1/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>>> >>> >>> > > From alexey.ivanov at oracle.com Thu Apr 2 17:55:40 2020 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 2 Apr 2020 18:55:40 +0100 Subject: RFR: 8233584: [Win LAF] When navigating the contents of the file list changes in Win LAF In-Reply-To: <3e20ef5a-6549-0a8e-d017-fc71bff92de6@oracle.com> References: <60d5b758-df58-9ba7-04a4-1603fa205263@oracle.com> <33cfebf6-2eac-ea58-781b-d8c0283cda4a@oracle.com> <3e20ef5a-6549-0a8e-d017-fc71bff92de6@oracle.com> Message-ID: There's a typo in the quoted text, there should be no ?|? character. @requires os.family == "windows" On 01/04/2020 19:47, Alexey Ivanov wrote: > Shall we add > @requires |os.family == "windows" > to the test? Then it won't be even selected for running by jtreg. -- Regards, Alexey From prasanta.sadhukhan at oracle.com Thu Apr 2 18:06:01 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 2 Apr 2020 23:36:01 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <2b39d545-0f0c-d6da-cfc0-f989a071fe4d@oracle.com> <4E01B9E7-0142-4345-8644-9F62CAE212CC@oracle.com> <195430c6-8890-8933-9f13-0eda88bb684a@oracle.com> <4e294d89-d320-56cb-6178-8da5b7c8649e@oracle.com>

<2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>

<23ffdef1-4dd2-7820-a57d-d4f6410302bf@oracle.com> <8757e954-b413-a68f-a6d7-7b2fd66cb6e1@oracle.com> <260266da-9c2d-ebb8-6af0-58bcf6162e04@oracle.com> <5c8527be-d47f-7052-124d-361b21b26e49@oracle.com> <3e37c6d4-4ddb-a829-7504-b2afd92b6996@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> Message-ID: On 02-Apr-20 10:04 PM, Prasanta Sadhukhan wrote: > > On 02-Apr-20 9:45 PM, Sergey Bylokhov wrote: >> On 4/1/20 1:03 am, Prasanta Sadhukhan wrote: >>> It is because of the same issue the size is not updated as >>> ToolTipManager#showTipWindow() calls popupFactory.getPopup() before >>> tip.show() and as per flow, >>> >>> getPopup() => getLightWeightPopup() => popup.reset() => pack() calls >>> component.setSize(component.getPreferredSize()) where the >>> preferredSize is not yet updated. >> >> It does not updated because it uses the wrong graphics configuration >> and as a result the wrong font metrics? >> Can we set correct GC as part of reset/pack steps for the popup? >> > As I told, the tip is not yet shown, so the graphicsConfiguration > property is not yet fired so please appraise me how to set correct GC > in reset/pack step? As per my understanding, the GC is correct in reset/pack steps(we pass insideComponent which is JButton to getPopup() and it's defaultTransform is same as the scale we have for the window, which in this case is 1.25), but since "graphicsConfiguration" property is not fired, so BasicHTML.updateRender is not yet called so View is not yet updated, so the preferredSpan is not correct, which is used in preferredSize calculation so when setSize is called, it is set with wrong preferredSize, so I dont think it's because of wrong GC. >>> >>> Regards >>> Prasanta >>> On 01-Apr-20 5:11 AM, Sergey Bylokhov wrote: >>>> That looks much better! The only question I have is why the size is >>>> not updated - is it intentional behaviour or we can tweak it somehow. >>>> >>>> On 3/31/20 1:13 am, Prasanta Sadhukhan wrote: >>>>> View is updated by calling BasicHTML.updateRenderer when >>>>> "graphicsConfiguration" property is fired when tooltip is shown >>>>> via tip.show() in ToolTipManager. Now, we should be using the >>>>> updated preferredSize calculated by View.getPreferredSpan but >>>>> BasicToolTip#paint still uses the old size. Proposed fix is to use >>>>> the updated preferredSize. >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.2/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 28-Mar-20 8:49 AM, Sergey Bylokhov wrote: >>>>>> On 3/27/20 3:27 am, Prasanta Sadhukhan wrote: >>>>>>> >>>>>>> On 07-Dec-19 10:28 AM, Sergey Bylokhov wrote: >>>>>>>> On 12/6/19 7:24 pm, Prasanta Sadhukhan wrote: >>>>>>>>>> How other components which may use HTML inside calculates its >>>>>>>>>> preferred size? I do not remember that they additionally >>>>>>>>>> scale the values returned by the View. >>>>>>>>> >>>>>>>>> Maybe those components does not use preferredSize calculation >>>>>>>>> as JTooltip does. >>>>>>>> >>>>>>>> Even if it not used, the preferredSize of the components and >>>>>>>> views should return correct values. >>>>>>>> >>>>>>>> >>>>>>> getPreferredSize() is called from ToolTipManager but it is done >>>>>>> *before *calling Tooltip.show() which actually triggers >>>>>>> PropertyChangeEvent with "graphicsConfiguration" property. >>>>>>> >>>>>>> Now, View is updated by calling BasicHTML.updateRenderer() when >>>>>>> "graphicsConfiguration" property is fired to notify transform is >>>>>>> changed, so during preferredSize() call, the View has not yet >>>>>>> been updated with correct transform. >>>>>> >>>>>> It means that the View should use GCOnfig of its >>>>>> parent-parent-etc, which is default/main GC if the >>>>>> components/windows are invisible or the GC of the real screen >>>>>> where the component/window is located. Or the size of the tooltip >>>>>> should be revalidated at the moment we found that the preferred >>>>>> size was calculated using the wrong GC. >>>>>> >>>>>> I think we should do both steps above. >>>>>> >>>>>> >>>>>> Note that we should never calculate "coordinate_XY * scale" and >>>>>> return this value to the user. The result of "coord*scale" should >>>>>> be only used when we pass the data to the native code, in all >>>>>> other places we should use just plain coordinates in the user's >>>>>> space. >>>>>> >>>>>>> So, my proposed fix is still same >>>>>>> >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.1/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>> >>>>>> >>>> >>>> >> >> From Sergey.Bylokhov at oracle.com Thu Apr 2 18:39:23 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 2 Apr 2020 11:39:23 -0700 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <4E01B9E7-0142-4345-8644-9F62CAE212CC@oracle.com> <195430c6-8890-8933-9f13-0eda88bb684a@oracle.com> <4e294d89-d320-56cb-6178-8da5b7c8649e@oracle.com>

<2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>

Message-ID: <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> On 4/2/20 11:06 am, Prasanta Sadhukhan wrote: > As per my understanding, the GC is correct in reset/pack steps(we pass insideComponent which is JButton to getPopup() and it's defaultTransform is same as the scale we have for the window, which in this case is 1.25), but since "graphicsConfiguration" property is not fired, so BasicHTML.updateRender is not yet called so View is not yet updated, so the preferredSpan is not correct, which is used in preferredSize calculation so when setSize is called, it is set with wrong preferredSize, so I dont think it's because of wrong GC. If we GC is correct in reset/pack step, but the View calculate wrong size(and update it only after "graphicsConfiguration" property change) means that we calculate the size of the View using wrong GC, why? -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Apr 3 03:59:11 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 3 Apr 2020 09:29:11 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <195430c6-8890-8933-9f13-0eda88bb684a@oracle.com> <4e294d89-d320-56cb-6178-8da5b7c8649e@oracle.com>

<2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>

<958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> Message-ID: <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> On 03-Apr-20 12:09 AM, Sergey Bylokhov wrote: > On 4/2/20 11:06 am, Prasanta Sadhukhan wrote: >> As per my understanding, the GC is correct in reset/pack steps(we >> pass insideComponent which is JButton to getPopup() and it's >> defaultTransform is same as the scale we have for the window, which >> in this case is 1.25), but since "graphicsConfiguration" property is >> not fired, so BasicHTML.updateRender is not yet called so View is not >> yet updated, so the preferredSpan is not correct, which is used in >> preferredSize calculation so when setSize is called, it is set with >> wrong preferredSize, so I dont think it's because of wrong GC. > > If we GC is correct in reset/pack step, but the View calculate wrong > size(and update it only after "graphicsConfiguration" property change) > means that we calculate the size of the View using wrong GC, why? It's not the size of View, it's the preferredSize that is wrong. This is because tip's GC is null before the tip is shown, so View's span is calculated accordingly. Only when View isupdated when "graphicsConfiguration" is fired, then Tooltip GC is updated and preferredSpan is calculated correctly. It's to be remembered that the issue happens only when html text is shown in ToolTip. If normal text is shown , there is no issue. I guess if it's a question of wrong GC during popup reset/pack, then it will cause problem during normal text rendering also, no? Regards Prasanta From Sergey.Bylokhov at oracle.com Sun Apr 5 04:59:32 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 4 Apr 2020 21:59:32 -0700 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <4e294d89-d320-56cb-6178-8da5b7c8649e@oracle.com>

<2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>

<958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> Message-ID: <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> On 4/2/20 8:59 pm, Prasanta Sadhukhan wrote: >> If we GC is correct in reset/pack step, but the View calculate wrong size(and update it only after "graphicsConfiguration" property change) means that we calculate the size of the View using wrong GC, why? > > It's not the size of View, it's the preferredSize that is wrong. This is because tip's GC is null before the tip is shown, so View's span is calculated accordingly. Only when View isupdated when "graphicsConfiguration" is fired, then Tooltip GC is updated and preferredSpan is calculated correctly. > > It's to be remembered that the issue happens only when html text is shown in ToolTip. If normal text is shown , there is no issue. I guess if it's a question of wrong GC during popup reset/pack, then it will cause problem during normal text rendering also, no? If GC of the tip is null before showing then can we use default screen GC by default? Same as in the java.awt.Window.initGC(). -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Apr 6 06:08:06 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 6 Apr 2020 11:38:06 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <4e294d89-d320-56cb-6178-8da5b7c8649e@oracle.com>

<2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>

<958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> Message-ID: <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> On 05-Apr-20 10:29 AM, Sergey Bylokhov wrote: > On 4/2/20 8:59 pm, Prasanta Sadhukhan wrote: > >>> If we GC is correct in reset/pack step, but the View calculate wrong >>> size(and update it only after "graphicsConfiguration" property >>> change) means that we calculate the size of the View using wrong GC, >>> why? >> >> It's not the size of View, it's the preferredSize that is wrong. This >> is because tip's GC is null before the tip is shown, so View's span >> is calculated accordingly. Only when View isupdated when >> "graphicsConfiguration" is fired, then Tooltip GC is updated and >> preferredSpan is calculated correctly. >> >> It's to be remembered that the issue happens only when html text is >> shown in ToolTip. If normal text is shown , there is no issue. I >> guess if it's a question of wrong GC during popup reset/pack, then it >> will cause problem during normal text rendering also, no? > > If GC of the tip is null before showing then can we use default screen > GC by default? Same as in the java.awt.Window.initGC(). I tried but SwingUtilities.windowForComponent(tip) returns null so there is no "Window" parent associated with tooltip so initGC() cannot be called on tip, as I see. Also, tip GC is null for normal text too, where it works. Only difference between normal and html text is in calculation of getPreferredSize/MaximumSize/MinimumSize where the size is updated based on updated span calculation, so I have used updated preferredSize in my fix. Regards Prasanta > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhawesh.choudhary at oracle.com Mon Apr 6 06:52:08 2020 From: bhawesh.choudhary at oracle.com (Bhawesh Choudhary) Date: Mon, 6 Apr 2020 12:22:08 +0530 Subject: RFR: 8233584: [Win LAF] When navigating the contents of the file list changes in Win LAF In-Reply-To: <3e20ef5a-6549-0a8e-d017-fc71bff92de6@oracle.com> References: <60d5b758-df58-9ba7-04a4-1603fa205263@oracle.com> <33cfebf6-2eac-ea58-781b-d8c0283cda4a@oracle.com> <3e20ef5a-6549-0a8e-d017-fc71bff92de6@oracle.com> Message-ID: Hi Alexey, Please find updated Webrev as per suggestion. I couldn't make test automatic due to not able to read contents currently being displayed in JFileChooser. JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.2/ -Bhawesh On 4/2/2020 12:17 AM, Alexey Ivanov wrote: > Hi Bhawesh, > > Shall we add > @requires |os.family == "windows" > to the test? Then it won't be even selected for running by jtreg. > > It think the copyright year should be updated in both modified files, > should it? > > I'd also suggest using explicit import statements for javax.swing.* > classes instead of the wildcard one. > > Is it possible to make the automatic? However, this is out of scope of > this bug. > > > Regards, > Alexey > | > On 31/03/2020 10:16, Bhawesh Choudhary wrote: >> Hi, >> >> Please find updated Webrev as per suggestions [Test case updates for >> WindowsLookAndFeel] >> >> JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 >> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.1/ >> >> -Bhawesh >> >> On 3/13/2020 12:10 PM, Bhawesh Choudhary wrote: >>> Hi, >>> >>> Please find updated Webrev as per suggestions [Test name update and >>> Code formatting] >>> >>> JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 >>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.01/ >>> >>> -Bhawesh >>> >>> On 3/4/2020 4:13 PM, Bhawesh Choudhary wrote: >>>> Hi, >>>> >>>> Please review this fix, >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev/ >>>> >>>> Issue: >>>> In Windows LookAndFeel, When navigating Combobox's list of >>>> JFileChooser via keys, the contents of JFileChooser changes. >>>> >>>> Fix: >>>> Set flag "JComboBox.isTableCellEditor" to True which prohibits >>>> JCombobox from sending selection change event when JCombobox's list >>>> selection change happens via keys. >>>> >>>> >>>> Verification: >>>> Tested the fix with JFileChooser with WindowsLookAndFeelEnabled as >>>> well as BasicLookAndFeel with keys navigation. also added a test >>>> case to verify the same. >>>> >>>> Did not find any misbehavior with the fix. >>>> >>>> Regards >>>> Bhawesh From Sergey.Bylokhov at oracle.com Mon Apr 6 06:56:18 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 5 Apr 2020 23:56:18 -0700 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com>

<2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>

<958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> Message-ID: <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> On 06-Apr-20 12:26 PM, Sergey Bylokhov wrote: > On 4/5/20 11:08 pm, Prasanta Sadhukhan wrote: >> >> On 05-Apr-20 10:29 AM, Sergey Bylokhov wrote: >>> On 4/2/20 8:59 pm, Prasanta Sadhukhan wrote: >>> >>>>> If we GC is correct in reset/pack step, but the View calculate >>>>> wrong size(and update it only after "graphicsConfiguration" >>>>> property change) means that we calculate the size of the View >>>>> using wrong GC, why? >>>> >>>> It's not the size of View, it's the preferredSize that is wrong. >>>> This is because tip's GC is null before the tip is shown, so View's >>>> span is calculated accordingly. Only when View isupdated when >>>> "graphicsConfiguration" is fired, then Tooltip GC is updated and >>>> preferredSpan is calculated correctly. >>>> >>>> It's to be remembered that the issue happens only when html text is >>>> shown in ToolTip. If normal text is shown , there is no issue. I >>>> guess if it's a question of wrong GC during popup reset/pack, then >>>> it will cause problem during normal text rendering also, no? >>> >>> If GC of the tip is null before showing then can we use default >>> screen GC by default? Same as in the java.awt.Window.initGC(). >> >> I tried but SwingUtilities.windowForComponent(tip) returns null so >> there is no "Window" parent associated with tooltip so initGC() >> cannot be called on tip, as I see. >> >> Also, tip GC is null for normal text too, where it works. Only >> difference between normal and html text is in calculation of >> getPreferredSize/MaximumSize/MinimumSize where the size is updated >> based on updated span calculation, so I have used updated >> preferredSize in my fix. > > The normal text may work because the text and font metrics produce the > "correct" size which is not changed on the scaled screen, while the > HTML produce different size depending on the font metrics. Note that > you should not call Window.initGC() but use the similar logic > somewhere in the code which initialize/show tip. I tried similar logic in ToolTipManager when the tip is created but to no effect. Even though BasicHTML.updateRenderer() is called but preferredSize is not updated, since JTooltip width/height was coming as 0x0 in BasicToolTipUI#propertyChange() ???????????? tip = insideComponent.createToolTip(); ???????????? tip.setTipText(toolTipText); + +??????????? System.out.println("default gc " + gc.getDefaultTransform()); +??????????? System.out.println("insideComponent GC " + insideComponent.getGraphicsConfiguration().getDefaultTransform()); +??????????? GraphicsConfiguration oldConfig = tip.getGraphicsConfiguration(); +??????????? System.out.println("tip oldgc " + tip.getGraphicsConfiguration()); +??????????? GraphicsConfiguration newConfig = tip.getGraphicsConfiguration(); +??????????? if (newConfig == null) { +??????????????? newConfig = GraphicsEnvironment.getLocalGraphicsEnvironment(). + getDefaultScreenDevice().getDefaultConfiguration(); +??????????? } +??????????? System.out.println("newgc " + newConfig); +??????????? if (newConfig != null) System.out.println(" transform " + newConfig.getDefaultTransform()); +??????????? tip.firePropertyChange("graphicsConfiguration", oldConfig, newConfig); + + ???????????? size = tip.getPreferredSize(); +??????????? System.out.println("tip preferredsize " + size); ???????????? if(preferredLocation != null) { ???????????????? location = toFind; > > From Sergey.Bylokhov at oracle.com Mon Apr 6 13:57:43 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 6 Apr 2020 06:57:43 -0700 Subject: RFR: 7105119 [TEST_BUG] [macosx] In test UIDefaults.toString() mast be called with the invokeLater() Message-ID: <414bee3d-a0ab-3131-8529-f55de26b53dc@oracle.com> Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-7105119 Fix: http://cr.openjdk.java.net/~serb/7105119/webrev.00 The code in the test was wrapped by the invokeAndWait, also the loop for all L&Fs was added just in case. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Tue Apr 7 12:54:58 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 7 Apr 2020 18:24:58 +0530 Subject: RFR JDK-8240877: NPE at javax.swing.text.html.FormView.appendBuffer with null option values Message-ID: <77482881-e8c5-6e25-a48d-935477315aa9@oracle.com> Hi All, Please review a fix for an issue where it is seen that javax.swing.text.html.FormView.appendBuffer will throw an NPE if "select" option value is null. This is because FormView#appendBuffer calls URLEncoder.encode(String s)? where it does new StringBuilder(s.length()); without verifying if "s" is null or not, so proposed fix is to check for null string. Bug: https://bugs.openjdk.java.net/browse/JDK-8240877 webrev: cr.openjdk.java.net/~psadhukhan/8240877/webrev.0/ Regards Prasanta From pankaj.b.bansal at oracle.com Tue Apr 7 16:01:39 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 7 Apr 2020 09:01:39 -0700 (PDT) Subject: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue In-Reply-To: <0D81D11D-910C-4B0F-AF02-E3D768F21D6C@sap.com> References: <92ca9fe1-6bbc-47c6-bc62-3f78ae7c7194@oracle.com> <4db1f723-0f5a-4d66-8db6-529897885d79@default>

<4cfd1bd2-0a45-4b23-97a3-e1a773db1785@default>

Message-ID: <1c505df1-299f-3bcd-c630-f143638b7d5a@oracle.com> On 4/8/20 1:56 am, Prasanta Sadhukhan wrote: > Not sure what you are pointing to...But, we already had code in loadElementDataIntoBuffer() where if value is null, then appendBuffer() is not called. I just extrapolated it to 2 other cases. So we do not need to use empty string here? > > Regards > Prasant > On 08-Apr-20 2:23 PM, Sergey Bylokhov wrote: >> HI, Prasanta. >> >> I am not sure what we should do in this code, but did you check >> other possible solutions like using empty value instead of null? >> >> On 4/7/20 5:54 am, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that javax.swing.text.html.FormView.appendBuffer will throw an NPE if "select" option value is null. >>> >>> This is because FormView#appendBuffer calls URLEncoder.encode(String s) where it does new StringBuilder(s.length()); without verifying if "s" is null or not, >>> >>> so proposed fix is to check for null string. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8240877 >>> >>> webrev: cr.openjdk.java.net/~psadhukhan/8240877/webrev.0/ >>> >>> Regards >>> Prasanta >> >> -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Apr 8 09:11:54 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 8 Apr 2020 14:41:54 +0530 Subject: RFR JDK-8240877: NPE at javax.swing.text.html.FormView.appendBuffer with null option values In-Reply-To: <1c505df1-299f-3bcd-c630-f143638b7d5a@oracle.com> References: <77482881-e8c5-6e25-a48d-935477315aa9@oracle.com>

<1c505df1-299f-3bcd-c630-f143638b7d5a@oracle.com> Message-ID: On 08-Apr-20 2:40 PM, Sergey Bylokhov wrote: > On 4/8/20 1:56 am, Prasanta Sadhukhan wrote: >> Not sure what you are pointing to...But, we already had code in >> loadElementDataIntoBuffer() where if value is null, then >> appendBuffer() is not called. I just extrapolated it to 2 other cases. > > So we do not need to use empty string here? > No, I dont think so. >> >> Regards >> Prasant >> On 08-Apr-20 2:23 PM, Sergey Bylokhov wrote: >>> HI, Prasanta. >>> >>> I am not sure what we should do in this code, but did you check >>> other possible solutions like using empty value instead of null? >>> >>> On 4/7/20 5:54 am, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue where it is seen that >>>> javax.swing.text.html.FormView.appendBuffer will throw an NPE if >>>> "select" option value is null. >>>> >>>> This is because FormView#appendBuffer calls >>>> URLEncoder.encode(String s) where it does new >>>> StringBuilder(s.length()); without verifying if "s" is null or not, >>>> >>>> so proposed fix is to check for null string. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8240877 >>>> >>>> webrev: cr.openjdk.java.net/~psadhukhan/8240877/webrev.0/ >>>> >>>> Regards >>>> Prasanta >>> >>> > > From Sergey.Bylokhov at oracle.com Wed Apr 8 09:12:36 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 8 Apr 2020 02:12:36 -0700 Subject: RFR JDK-8240877: NPE at javax.swing.text.html.FormView.appendBuffer with null option values In-Reply-To: References: <77482881-e8c5-6e25-a48d-935477315aa9@oracle.com>

<1c505df1-299f-3bcd-c630-f143638b7d5a@oracle.com> Message-ID: <8999404c-22bb-9c3b-76da-4667668c01d9@oracle.com> On 4/8/20 2:11 am, Prasanta Sadhukhan wrote: > > On 08-Apr-20 2:40 PM, Sergey Bylokhov wrote: >> On 4/8/20 1:56 am, Prasanta Sadhukhan wrote: >>> Not sure what you are pointing to...But, we already had code in loadElementDataIntoBuffer() where if value is null, then appendBuffer() is not called. I just extrapolated it to 2 other cases. >> >> So we do not need to use empty string here? >> > No, I dont think so. ok, +1 >>> >>> Regards >>> Prasant >>> On 08-Apr-20 2:23 PM, Sergey Bylokhov wrote: >>>> HI, Prasanta. >>>> >>>> I am not sure what we should do in this code, but did you check >>>> other possible solutions like using empty value instead of null? >>>> >>>> On 4/7/20 5:54 am, Prasanta Sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for an issue where it is seen that javax.swing.text.html.FormView.appendBuffer will throw an NPE if "select" option value is null. >>>>> >>>>> This is because FormView#appendBuffer calls URLEncoder.encode(String s) where it does new StringBuilder(s.length()); without verifying if "s" is null or not, >>>>> >>>>> so proposed fix is to check for null string. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8240877 >>>>> >>>>> webrev: cr.openjdk.java.net/~psadhukhan/8240877/webrev.0/ >>>>> >>>>> Regards >>>>> Prasanta >>>> >>>> >> >> -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Apr 8 12:17:59 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 8 Apr 2020 17:47:59 +0530 Subject: RFR JDK-8213123:javax/swing/JButton/4368790/bug4368790.java fails on mac Message-ID: Hi All, Please review a fix for an issue where it is seen that in macOS, JButton remains pressed even when the focus is lost. This was fixed inJDK-4368790: JButton stays pressed when focus stolen by calling setPressed(false) for BasicButtonListener created in BasicButtonUI#installListener for other L&Fs, but it fails for default AquaL&F in macOS. The same needs to be done in AquaButtonListener created in AquaButtonUI#installListener for mac Bug: https://bugs.openjdk.java.net/browse/JDK-8213123 webrev: http://cr.openjdk.java.net/~psadhukhan/8213123/webrev.0/ Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Apr 8 20:38:39 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 8 Apr 2020 13:38:39 -0700 Subject: RFR JDK-8213123:javax/swing/JButton/4368790/bug4368790.java fails on mac In-Reply-To: References: Message-ID: <05b545c2-2519-1677-2646-43b5d8ed8159@oracle.com> Hi, Prasanta. Could you confirm that other non-default L&F does not have this bug, probably it would be good to check that in the test? On 4/8/20 5:17 am, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that in macOS, JButton remains pressed even when the focus is lost. > > This was fixed inJDK-4368790: JButton stays pressed when focus stolen by calling setPressed(false) for BasicButtonListener created in BasicButtonUI#installListener for other L&Fs, but it fails for default AquaL&F in macOS. > > The same needs to be done in AquaButtonListener created in AquaButtonUI#installListener for mac > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213123 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8213123/webrev.0/ > > Regards > Prasanta -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Apr 9 05:14:52 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 9 Apr 2020 10:44:52 +0530 Subject: RFR JDK-8213123:javax/swing/JButton/4368790/bug4368790.java fails on mac In-Reply-To: <05b545c2-2519-1677-2646-43b5d8ed8159@oracle.com> References: <05b545c2-2519-1677-2646-43b5d8ed8159@oracle.com> Message-ID: <1155d852-9cd5-8c14-7065-4da56c788ae0@oracle.com> Yes, other L&F does not have this bug as confirmed by updated test testing all installed L&Fs http://cr.openjdk.java.net/~psadhukhan/8213123/webrev.1/ Regards Prasanta On 09-Apr-20 2:08 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > > Could you confirm that other non-default L&F does not have this bug, > probably it would be good to check that in the test? > > > On 4/8/20 5:17 am, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that in macOS, >> JButton remains pressed even when the focus is lost. >> >> This was fixed inJDK-4368790: >> JButton stays >> pressed when focus stolen by calling setPressed(false) for >> BasicButtonListener created in BasicButtonUI#installListener for >> other L&Fs, but it fails for default AquaL&F in macOS. >> >> The same needs to be done in AquaButtonListener created in >> AquaButtonUI#installListener for mac >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213123 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8213123/webrev.0/ >> >> Regards >> Prasanta > > From takiguc at linux.vnet.ibm.com Thu Apr 9 09:24:54 2020 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 09 Apr 2020 18:24:54 +0900 Subject: RFR: 8241493 [macos] Swing PrintDialog attributes issues Message-ID: <99ce66eb9b6f60ea8b6df5c044ad6f57@linux.vnet.ibm.com> Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8241493 Change: https://cr.openjdk.java.net/~itakiguchi/8241493/webrev.00/ JDK-8241493 [1] is related to Swing's print dialog, mainly macOS's CUPS. It may improve user interoperability. I appreciate your feedback and suggestions. [1] https://bugs.openjdk.java.net/browse/JDK-8241493 Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From Sergey.Bylokhov at oracle.com Thu Apr 9 11:35:37 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 9 Apr 2020 04:35:37 -0700 Subject: RFR JDK-8213123:javax/swing/JButton/4368790/bug4368790.java fails on mac In-Reply-To: <1155d852-9cd5-8c14-7065-4da56c788ae0@oracle.com> References: <05b545c2-2519-1677-2646-43b5d8ed8159@oracle.com> <1155d852-9cd5-8c14-7065-4da56c788ae0@oracle.com> Message-ID: Looks fine. On 4/8/20 10:14 pm, Prasanta Sadhukhan wrote: > Yes, other L&F does not have this bug as confirmed by updated test testing all installed L&Fs > > http://cr.openjdk.java.net/~psadhukhan/8213123/webrev.1/ > > Regards > Prasanta > On 09-Apr-20 2:08 AM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> >> Could you confirm that other non-default L&F does not have this bug, probably it would be good to check that in the test? >> >> >> On 4/8/20 5:17 am, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that in macOS, JButton remains pressed even when the focus is lost. >>> >>> This was fixed inJDK-4368790: JButton stays pressed when focus stolen by calling setPressed(false) for BasicButtonListener created in BasicButtonUI#installListener for other L&Fs, but it fails for default AquaL&F in macOS. >>> >>> The same needs to be done in AquaButtonListener created in AquaButtonUI#installListener for mac >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213123 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8213123/webrev.0/ >>> >>> Regards >>> Prasanta >> >> -- Best regards, Sergey. From philip.race at oracle.com Fri Apr 10 16:54:39 2020 From: philip.race at oracle.com (Philip Race) Date: Fri, 10 Apr 2020 09:54:39 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8241493 [macos] Swing PrintDialog attributes issues In-Reply-To: <99ce66eb9b6f60ea8b6df5c044ad6f57@linux.vnet.ibm.com> References: <99ce66eb9b6f60ea8b6df5c044ad6f57@linux.vnet.ibm.com> Message-ID: <5E90A4CF.5050806@oracle.com> Could you describe here the ideas behind your fix and what the implications are 1) I'm sure I've seen printers that describe the same paper size by multiple names. Why is it a problem here ? If it is because we have the same display name, is that just for known standard sizes ? Can we get the printer's display name for this ? 2) You are changing what is in "asCurrent", so if the user switches back to the printer supporting duplex that is lost. I think in other cases we update the display but not the current attribute set. So are you swapping one anomaly for another ? What is the user model ? Suppose printer 1 supports all 3, printer 2 supports ONE_SIDED and DUPLEX, but not TUMBLE. User selects TUMBLE on printer 1, switches to printer 2, what should they see ? Probably the default for that printer, but no need to update asCurrent, since if they print the attribute is ignored anyway But doing it that way if they switch back to printer 1, lo and behold, we still have TUMBLE. The catch is that the user may in fact be surprised by that. Paper too has the same issue. If you have a printer supporting A3, and switch a one that doesn't support it, do we update the aset. If we do it for SIDES, we should do it there too. And what happens if you use the native dialog instead ? So if you are touching this you need to examine the whole picture first. -phil. On 4/9/20, 2:24 AM, Ichiroh Takiguchi wrote: > Hello. > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241493 > Change: https://cr.openjdk.java.net/~itakiguchi/8241493/webrev.00/ > > JDK-8241493 [1] is related to Swing's print dialog, mainly macOS's CUPS. > It may improve user interoperability. > > I appreciate your feedback and suggestions. > > [1] https://bugs.openjdk.java.net/browse/JDK-8241493 > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. From tejpal.rebari at oracle.com Sat Apr 11 12:28:27 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Sat, 11 Apr 2020 17:58:27 +0530 Subject: RFR: 8241228 Test jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java is failing In-Reply-To: <82efc12f-8738-a100-0143-5cce95531218@oracle.com> References: <524b95bf-d8f5-727d-8f33-303e21254dc8@oracle.com> <7EFC3577-65F8-45D0-A085-A5B0B4EC3220@oracle.com> <82efc12f-8738-a100-0143-5cce95531218@oracle.com> Message-ID: Hi All, JDK-8241491 is merged to jdk/client and I have removed aix-all and updated the webrev. http://cr.openjdk.java.net/~trebari/swing/8241228/webrev01/ Thanks and regards Tejpal > On 31-Mar-2020, at 12:54 PM, Prasanta Sadhukhan wrote: > > I think for this bug only, you can create a webrev out of jdk/jdk with this fix and an updated problem list removing aix-all and commit that in jdk/jdk directly. > > Regards > Prasanta > On 31-Mar-20 11:35 AM, Tejpal Rebari wrote: >> Hi Sergey, >> >>> On 31-Mar-2020, at 11:14 AM, Sergey Bylokhov > wrote: >>> >>> Hi, Tejpal. >>> >>> The fix looks fine, but you need to wait until the fix for JDK-8241491 >>> will not be merged to JDK/client, otherwise, the merge conflict will occur. >> >> >> JDK-8241491 is problem listing the test for aix-all. >> I think after the merge we need to remove aix-all from the problemlist as well. >> >> Regards >> Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Sat Apr 11 14:09:38 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 11 Apr 2020 07:09:38 -0700 Subject: RFR: 8241228 Test jdk/javax/swing/UIDefaults/8146330/UIDefaultKeySizeTest.java is failing In-Reply-To: References: <524b95bf-d8f5-727d-8f33-303e21254dc8@oracle.com> <7EFC3577-65F8-45D0-A085-A5B0B4EC3220@oracle.com> <82efc12f-8738-a100-0143-5cce95531218@oracle.com> Message-ID: Looks fine. On 4/11/20 5:28 am, Tejpal Rebari wrote: > Hi All, > JDK-8241491 is merged to jdk/client and I have removed aix-all and updated the webrev. > http://cr.openjdk.java.net/~trebari/swing/8241228/webrev01/ > > Thanks and regards > Tejpal > >> On 31-Mar-2020, at 12:54 PM, Prasanta Sadhukhan > wrote: >> >> I think for this bug only, you can create a webrev out of jdk/jdk with this fix? and an updated problem list removing aix-all and commit that in jdk/jdk directly. >> >> Regards >> Prasanta >> On 31-Mar-20 11:35 AM, Tejpal Rebari wrote: >>> Hi Sergey, >>> >>>> On 31-Mar-2020, at 11:14 AM, Sergey Bylokhov > wrote: >>>> >>>> Hi, Tejpal. >>>> >>>> The fix looks fine, but you need to wait until the fix for JDK-8241491 >>>> will not be merged to JDK/client, otherwise, the merge conflict will occur. >>> >>> JDK-8241491 is problem listing ?the test for aix-all. >>> I think after the merge we need to remove aix-all from the problemlist as well. >>> >>> Regards >>> Tejpal > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Sat Apr 11 14:13:25 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 11 Apr 2020 07:13:25 -0700 (PDT) Subject: RFR JDK-8242526: PIT: javax/swing/JInternalFrame/8020708/bug8020708.java fails in mach5 ubuntu system Message-ID: <1ef7f4dd-ad49-5523-4a44-9c7c642c76f0@oracle.com> Hi All, Please review a test fix for an issue seen in PIT where the test is failing on ubuntu 18.04 on mach5 system The previous 8226230 fix fixes the issue in local ubuntu18.04 but it seems it sometimes still fail in mach5 ubuntu system. Added some delay to ensure it passes in mach5 system too. Also, added debug message to show added log if it fails again in some other system. Bug: https://bugs.openjdk.java.net/browse/JDK-8242526 webrev: http://cr.openjdk.java.net/~psadhukhan/8242526/webrev.0/ mach5 job trying several times is linked to JBS is green. Regards Prasanta From Sergey.Bylokhov at oracle.com Sat Apr 11 14:38:08 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 11 Apr 2020 07:38:08 -0700 Subject: RFR JDK-8242526: PIT: javax/swing/JInternalFrame/8020708/bug8020708.java fails in mach5 ubuntu system In-Reply-To: <1ef7f4dd-ad49-5523-4a44-9c7c642c76f0@oracle.com> References: <1ef7f4dd-ad49-5523-4a44-9c7c642c76f0@oracle.com> Message-ID: Hi, Prasanta. Not sure that "waitForIdle()" should be removed at line 107, it waits till the moment the window became visible, and w/o it the Util.getCenterPoint may return wrong coordinates. It is also unclear how the robot.delay(500); after the "hitKeys" will help, since the buttons were pressed already, and we additionally will wait for what? On 4/11/20 7:13 am, Prasanta Sadhukhan wrote: > Hi All, > > Please review a test fix for an issue seen in PIT where the test is failing on ubuntu 18.04 on mach5 system > > The previous 8226230 fix fixes the issue in local ubuntu18.04 but it seems it sometimes still fail in mach5 ubuntu system. > > Added some delay to ensure it passes in mach5 system too. Also, added debug message to show added log if it fails again in some other system. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242526 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8242526/webrev.0/ > > mach5 job trying several times is linked to JBS is green. > > Regards > Prasanta -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Sat Apr 11 16:16:46 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 11 Apr 2020 21:46:46 +0530 Subject: RFR JDK-8242526: PIT: javax/swing/JInternalFrame/8020708/bug8020708.java fails in mach5 ubuntu system In-Reply-To: References: <1ef7f4dd-ad49-5523-4a44-9c7c642c76f0@oracle.com> Message-ID: On 11-Apr-20 8:08 PM, Sergey Bylokhov wrote: > Hi, Prasanta. > > Not sure that "waitForIdle()" should be removed at line 107, it waits > till the moment the window became visible, > and w/o it the Util.getCenterPoint may return wrong coordinates. > > It is also unclear how the robot.delay(500); after the "hitKeys" will > help, since the buttons > were pressed already, and we additionally will wait for what? > OK. I have added waitForIdle() but I have retained delay as we still need to hit VK_C after SHIFT+ESC. It passes 100 iterations of mach5 testing. http://cr.openjdk.java.net/~psadhukhan/8242526/webrev.1/ Regards Prasanta > On 4/11/20 7:13 am, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a test fix for an issue seen in PIT where the test is >> failing on ubuntu 18.04 on mach5 system >> >> The previous 8226230 fix fixes the issue in local ubuntu18.04 but it >> seems it sometimes still fail in mach5 ubuntu system. >> >> Added some delay to ensure it passes in mach5 system too. Also, added >> debug message to show added log if it fails again in some other system. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8242526 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8242526/webrev.0/ >> >> mach5 job trying several times is linked to JBS is green. >> >> Regards >> Prasanta > > From Sergey.Bylokhov at oracle.com Sun Apr 12 01:49:31 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 11 Apr 2020 18:49:31 -0700 Subject: RFR JDK-8242526: PIT: javax/swing/JInternalFrame/8020708/bug8020708.java fails in mach5 ubuntu system In-Reply-To: References: <1ef7f4dd-ad49-5523-4a44-9c7c642c76f0@oracle.com>

Message-ID: <2fc8ad77-e547-c591-4270-79d9b389384d@oracle.com> +1 On 4/11/20 9:16 am, Prasanta Sadhukhan wrote: > > On 11-Apr-20 8:08 PM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> >> Not sure that "waitForIdle()" should be removed at line 107, it waits till the moment the window became visible, >> and w/o it the Util.getCenterPoint may return wrong coordinates. >> >> It is also unclear how the robot.delay(500); after the "hitKeys" will help, since the buttons >> were pressed already, and we additionally will wait for what? >> > OK. I have added waitForIdle() but I have retained delay as we still need to hit VK_C after SHIFT+ESC. > > It passes 100 iterations of mach5 testing. > > http://cr.openjdk.java.net/~psadhukhan/8242526/webrev.1/ > > Regards > Prasanta >> On 4/11/20 7:13 am, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a test fix for an issue seen in PIT where the test is failing on ubuntu 18.04 on mach5 system >>> >>> The previous 8226230 fix fixes the issue in local ubuntu18.04 but it seems it sometimes still fail in mach5 ubuntu system. >>> >>> Added some delay to ensure it passes in mach5 system too. Also, added debug message to show added log if it fails again in some other system. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242526 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8242526/webrev.0/ >>> >>> mach5 job trying several times is linked to JBS is green. >>> >>> Regards >>> Prasanta >> >> -- Best regards, Sergey. From pankaj.b.bansal at oracle.com Sun Apr 12 14:37:29 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Sun, 12 Apr 2020 07:37:29 -0700 (PDT) Subject: RFR: 8152332 [macosx] JFileChooser cannot be serialized on Mac OS X In-Reply-To: <31af916b-b107-4b9e-93d1-d2413de8e760@default> References: <31af916b-b107-4b9e-93d1-d2413de8e760@default> Message-ID: Looks good to me. One minor nit, don?t we need to add the current bug id to the test? -Pankaj -----Original Message----- From: Sergey Bylokhov Sent: Monday, March 16, 2020 2:06 PM To: Swing-Dev Subject: RFR: 8152332 [macosx] JFileChooser cannot be serialized on Mac OS X Hello. Please review the fix for JDK/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8152332 Fix: http://cr.openjdk.java.net/~serb/8152332/webrev.00 This test failed because of two product bugs JDK-8240633 and JDK-8240690(still under review). But there is an issue in the test itself, it uses a sequence of robot events which does not work on L&Fs such as Aqua/Nimbus but works on Metal. The test was updated to close the file chooser w/o robot, and the default button is verified explicitly, also added a check for all L&Fs. I have checked that it is possible to verify the initial bug JDK-8146301 using an updated test. -- Best regards, Sergey. From pankaj.b.bansal at oracle.com Mon Apr 13 08:35:01 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 13 Apr 2020 14:05:01 +0530 Subject: RFR JDK-8242526: PIT: javax/swing/JInternalFrame/8020708/bug8020708.java fails in mach5 ubuntu system In-Reply-To: References: <1ef7f4dd-ad49-5523-4a44-9c7c642c76f0@oracle.com>

Message-ID: Look good to me -Pankaj On 11/04/20 9:46 PM, Prasanta Sadhukhan wrote: > > On 11-Apr-20 8:08 PM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> >> Not sure that "waitForIdle()" should be removed at line 107, it waits >> till the moment the window became visible, >> and w/o it the Util.getCenterPoint may return wrong coordinates. >> >> It is also unclear how the robot.delay(500); after the "hitKeys" will >> help, since the buttons >> were pressed already, and we additionally will wait for what? >> > OK. I have added waitForIdle() but I have retained delay as we still > need to hit VK_C after SHIFT+ESC. > > It passes 100 iterations of mach5 testing. > > http://cr.openjdk.java.net/~psadhukhan/8242526/webrev.1/ > > Regards > Prasanta >> On 4/11/20 7:13 am, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a test fix for an issue seen in PIT where the test is >>> failing on ubuntu 18.04 on mach5 system >>> >>> The previous 8226230 fix fixes the issue in local ubuntu18.04 but it >>> seems it sometimes still fail in mach5 ubuntu system. >>> >>> Added some delay to ensure it passes in mach5 system too. Also, >>> added debug message to show added log if it fails again in some >>> other system. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242526 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8242526/webrev.0/ >>> >>> mach5 job trying several times is linked to JBS is green. >>> >>> Regards >>> Prasanta >> >> From prasanta.sadhukhan at oracle.com Mon Apr 13 10:06:07 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 13 Apr 2020 15:36:07 +0530 Subject: RFR JDK-8242410: JEditorPane with test/html type and zero margins is not shown Message-ID: <270d702e-87b1-4f68-a273-d5446af7d520@oracle.com> Hi All, Please review a fix for an issue where it is seen that when JEditorPane is created with empty text and zero top and bottom insets, the text is not shown after updating it by the method setText(String) This is because the the JEditorPane height is not updated and remains 0 if the margin top/botton insets are 0. Proposed fix is to check if the margin being set is less than default margin, then update the margin to the default. Bug: https://bugs.openjdk.java.net/browse/JDK-8242410 webrev: http://cr.openjdk.java.net/~psadhukhan/8242410/webrev.0/ I also considered changing getPreferredSize() to update the rootView size if height is 0, but it seems it has caused some regression in the past, so abstained from that /-else if (d.width == 0 && d.height == 0) {/ /+//else if (d.width == 0 || d.height == 0) {/ /??????????????? // Probably haven't been layed out yet, force some sort of// //??????????????? // initial sizing.// //??????????????? rootView.setSize(Integer.MAX_VALUE, Integer.MAX_VALUE);// //??????????? }/ Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Apr 13 13:03:06 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 13 Apr 2020 06:03:06 -0700 Subject: RFR: 8152332 [macosx] JFileChooser cannot be serialized on Mac OS X In-Reply-To: References: <31af916b-b107-4b9e-93d1-d2413de8e760@default> Message-ID: <8b928f62-798b-f5ef-4253-b18068da49a4@oracle.com> On 4/12/20 7:37 am, Pankaj Bansal wrote: > Looks good to me. Thank you. > One minor nit, don?t we need to add the current bug id to the test? Nope, that field mostly for the product bugs, which is useful when the test is updated, we need to check that the previous product bug still can be verified by the test, like I did in this fix and JDK-8146301. > > -Pankaj > > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, March 16, 2020 2:06 PM > To: Swing-Dev > Subject: RFR: 8152332 [macosx] JFileChooser cannot be serialized on Mac OS X > > Hello. > Please review the fix for JDK/client. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152332 > Fix: http://cr.openjdk.java.net/~serb/8152332/webrev.00 > > This test failed because of two product bugs > JDK-8240633 and JDK-8240690(still under review). > > But there is an issue in the test itself, it uses a sequence of robot events which does not work on L&Fs such as Aqua/Nimbus but works on Metal. The test was updated to close the file chooser w/o robot, and the default button is verified explicitly, also added a check for all L&Fs. > > I have checked that it is possible to verify the initial bug JDK-8146301 using an updated test. > > -- > Best regards, Sergey. > -- Best regards, Sergey. From JAYATHIRTH.D.V at ORACLE.COM Mon Apr 13 13:14:19 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Mon, 13 Apr 2020 18:44:19 +0530 Subject: RFR: 8152332 [macosx] JFileChooser cannot be serialized on Mac OS X In-Reply-To: <8b928f62-798b-f5ef-4253-b18068da49a4@oracle.com> References: <31af916b-b107-4b9e-93d1-d2413de8e760@default> <8b928f62-798b-f5ef-4253-b18068da49a4@oracle.com> Message-ID: <4AB0FE81-30CF-4D50-94A4-A4239BABA642@ORACLE.COM> +1. Regards, Jay > On 13-Apr-2020, at 6:33 PM, Sergey Bylokhov wrote: > > On 4/12/20 7:37 am, Pankaj Bansal wrote: >> Looks good to me. > > Thank you. > >> One minor nit, don?t we need to add the current bug id to the test? > > Nope, that field mostly for the product bugs, which is useful when the test is updated, > we need to check that the previous product bug still can be verified by the test, like > I did in this fix and JDK-8146301. > >> -Pankaj >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Monday, March 16, 2020 2:06 PM >> To: Swing-Dev >> Subject: RFR: 8152332 [macosx] JFileChooser cannot be serialized on Mac OS X >> Hello. >> Please review the fix for JDK/client. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152332 >> Fix: http://cr.openjdk.java.net/~serb/8152332/webrev.00 >> This test failed because of two product bugs >> JDK-8240633 and JDK-8240690(still under review). >> But there is an issue in the test itself, it uses a sequence of robot events which does not work on L&Fs such as Aqua/Nimbus but works on Metal. The test was updated to close the file chooser w/o robot, and the default button is verified explicitly, also added a check for all L&Fs. >> I have checked that it is possible to verify the initial bug JDK-8146301 using an updated test. >> -- >> Best regards, Sergey. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Apr 13 18:47:39 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 14 Apr 2020 00:17:39 +0530 Subject: RFR JDK-8233644, , [TESTBUG] JInternalFrame test bug8020708.java is failing on macos Message-ID: Hi All, The fix done for "8242526: PIT: javax/swing/JInternalFrame/8020708/bug8020708.java fails in mach5 ubuntu system" works for macOS too, so we can remove the test from ProblemList. Testing for 100 iterations on mach5 mac system works ok (link in JBS) Bug: https://bugs.openjdk.java.net/browse/JDK-8233644 diff -r 19afeaa0fdbe test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt? Sat Apr 11 10:32:17 2020 +0530 +++ b/test/jdk/ProblemList.txt? Mon Apr 13 23:58:32 2020 +0530 @@ -886,7 +886,6 @@ ?javax/swing/JMenuBar/4750590/bug4750590.java 8233642 macosx-all ?javax/swing/JMenu/4692443/bug4692443.java 8171998 macosx-all ?javax/swing/JMenu/4515762/bug4515762.java 8233643 macosx-all *-javax/swing/JInternalFrame/8020708/bug8020708.java 8233644 macosx-all* ?javax/swing/JColorChooser/Test8051548.java 8233647 macosx-all ?javax/swing/plaf/synth/7158712/bug7158712.java 8238720 windows-all Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Wed Apr 15 10:05:22 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 15 Apr 2020 12:05:22 +0200 Subject: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent In-Reply-To: <4363cce8-1507-f3e5-9e13-d7f96b044d31@oracle.com> References: <4363cce8-1507-f3e5-9e13-d7f96b044d31@oracle.com> Message-ID: Hi swing-dev, Do you have any other suggestions for how to resolve the deprecation of modelToView() in this code? Basically, the code does this: ?????? Rectangle rect = source.modelToView(offset); ?????? source.scrollRectToVisible(rect); but scrollRectToVisible() requires a Rectangle (a subtype of Rectangle2D), and modelToView() is deprecated with reference to modelToView2D(), which returns a Rectangle2D, which is thus unusable by scrollRectToVisible(). I also cannot find a way to create a new Rectangle, given a Rectangle2D. In practice, under the hood, it's still just Rectangles (not Rectangle2D). /Magnus On 2020-04-15 11:37, David Holmes wrote: > Hi Magnus, > > This one sounds like it needs a Swing/Java2D developer to review it :) > > Cheers, > David > > On 15/04/2020 7:13 pm, Magnus Ihse Bursie wrote: >> After JDK-8242804, a few places remain which are using deprecated >> methods. They too should be fixed, and the deprecation warning should >> no longer be disabled. >> >> This patch presupposes the fix for JDK-8242804 has been applied >> (otherwise we cannot turn the deprecation warning back on). >> >> Some brief comments about each fix: >> >> * In ConstantPool.java, there was a boxing deprecation that I missed >> in JDK-8242804 (sorry!) >> >> * In HighPrecisionJScrollBar.java, there is a trivial replacement to >> use BigDecimal.divide with RoundingMode semantics. >> >> * In SourceCodePanel.java, I settled for suppressing the warning. The >> issue here is that modelToView (which returns a Rectangle) is >> deprecated in favor of modelToView2D, which returns a Rectangle2D >> (which is a supertype of Rectangle). But we use the result in >> scrollRectToVisible, and there exist no version of that which accepts >> a Rectangle2D instead of a Rectangle, nor a way to created a >> Rectangle from a Rectangle2D (that I could find). In practice, this >> is just a game of types -- under the hood, modelToView2D still >> returns a Rectangle (even though it only promises a Rectangle2D). The >> alternative here would be to cast the result of modelToView2D to a >> Rectangle, but I found that less attractive. >> >> * In JTreeTable.java, I've replaced the use of the old-style modifier >> mask with the new-style extended modifier mask. To the best of my >> understanding, this will just work the same for the code here (and >> for the MouseEvent constructor, using the extended mask is actually >> prescribed). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8242808 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.01 >> >> From prasanta.sadhukhan at oracle.com Wed Apr 15 10:59:35 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 15 Apr 2020 16:29:35 +0530 Subject: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent In-Reply-To: References: <4363cce8-1507-f3e5-9e13-d7f96b044d31@oracle.com> Message-ID: Hi Magnus, Why can't we just use modelToView2D() to get Rectangle2D and then cast to Rectangle tobe used in scrollRectToVisible() or else use (int)Rectangle2D.getX(), (int)getY(), getWidth(), getHeight() to construct a new Rectangle()? Regard Prasanta On 15-Apr-20 3:35 PM, Magnus Ihse Bursie wrote: > Hi swing-dev, > > Do you have any other suggestions for how to resolve the deprecation > of modelToView() in this code? > > Basically, the code does this: > > ?????? Rectangle rect = source.modelToView(offset); > ?????? source.scrollRectToVisible(rect); > > but scrollRectToVisible() requires a Rectangle (a subtype of > Rectangle2D), and modelToView() is deprecated with reference to > modelToView2D(), which returns a Rectangle2D, which is thus unusable > by scrollRectToVisible(). I also cannot find a way to create a new > Rectangle, given a Rectangle2D. > > In practice, under the hood, it's still just Rectangles (not > Rectangle2D). > > /Magnus > > On 2020-04-15 11:37, David Holmes wrote: >> Hi Magnus, >> >> This one sounds like it needs a Swing/Java2D developer to review it :) >> >> Cheers, >> David >> >> On 15/04/2020 7:13 pm, Magnus Ihse Bursie wrote: >>> After JDK-8242804, a few places remain which are using deprecated >>> methods. They too should be fixed, and the deprecation warning >>> should no longer be disabled. >>> >>> This patch presupposes the fix for JDK-8242804 has been applied >>> (otherwise we cannot turn the deprecation warning back on). >>> >>> Some brief comments about each fix: >>> >>> * In ConstantPool.java, there was a boxing deprecation that I missed >>> in JDK-8242804 (sorry!) >>> >>> * In HighPrecisionJScrollBar.java, there is a trivial replacement to >>> use BigDecimal.divide with RoundingMode semantics. >>> >>> * In SourceCodePanel.java, I settled for suppressing the warning. >>> The issue here is that modelToView (which returns a Rectangle) is >>> deprecated in favor of modelToView2D, which returns a Rectangle2D >>> (which is a supertype of Rectangle). But we use the result in >>> scrollRectToVisible, and there exist no version of that which >>> accepts a Rectangle2D instead of a Rectangle, nor a way to created a >>> Rectangle from a Rectangle2D (that I could find). In practice, this >>> is just a game of types -- under the hood, modelToView2D still >>> returns a Rectangle (even though it only promises a Rectangle2D). >>> The alternative here would be to cast the result of modelToView2D to >>> a Rectangle, but I found that less attractive. >>> >>> * In JTreeTable.java, I've replaced the use of the old-style >>> modifier mask with the new-style extended modifier mask. To the best >>> of my understanding, this will just work the same for the code here >>> (and for the MouseEvent constructor, using the extended mask is >>> actually prescribed). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242808 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.01 >>> >>> > From Sergey.Bylokhov at oracle.com Wed Apr 15 11:41:08 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 15 Apr 2020 04:41:08 -0700 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <2ecd6664-42c3-f0ea-dba7-ec57728017d7@oracle.com>

Message-ID: <194c6cca-f6c5-5250-3dbf-5c03036c3280@oracle.com> On 2020-04-15 12:59, Prasanta Sadhukhan wrote: > Hi Magnus, > > Why can't we just use modelToView2D() to get Rectangle2D and then cast > to Rectangle tobe used in scrollRectToVisible() or else use > (int)Rectangle2D.getX(), (int)getY(), getWidth(), getHeight() to > construct a new Rectangle()? Casting a Rectangle2D to a Rectangle does not seem to me to be an improvement. That presupposes even more knowledge about implementation details. However, I'll look into constructing a Rectangle using the getters from the Rectangle2D, as you suggested. Thanks! /Magnus > > Regard > Prasanta > On 15-Apr-20 3:35 PM, Magnus Ihse Bursie wrote: >> Hi swing-dev, >> >> Do you have any other suggestions for how to resolve the deprecation >> of modelToView() in this code? >> >> Basically, the code does this: >> >> ?????? Rectangle rect = source.modelToView(offset); >> ?????? source.scrollRectToVisible(rect); >> >> but scrollRectToVisible() requires a Rectangle (a subtype of >> Rectangle2D), and modelToView() is deprecated with reference to >> modelToView2D(), which returns a Rectangle2D, which is thus unusable >> by scrollRectToVisible(). I also cannot find a way to create a new >> Rectangle, given a Rectangle2D. >> >> In practice, under the hood, it's still just Rectangles (not >> Rectangle2D). >> >> /Magnus >> >> On 2020-04-15 11:37, David Holmes wrote: >>> Hi Magnus, >>> >>> This one sounds like it needs a Swing/Java2D developer to review it :) >>> >>> Cheers, >>> David >>> >>> On 15/04/2020 7:13 pm, Magnus Ihse Bursie wrote: >>>> After JDK-8242804, a few places remain which are using deprecated >>>> methods. They too should be fixed, and the deprecation warning >>>> should no longer be disabled. >>>> >>>> This patch presupposes the fix for JDK-8242804 has been applied >>>> (otherwise we cannot turn the deprecation warning back on). >>>> >>>> Some brief comments about each fix: >>>> >>>> * In ConstantPool.java, there was a boxing deprecation that I >>>> missed in JDK-8242804 (sorry!) >>>> >>>> * In HighPrecisionJScrollBar.java, there is a trivial replacement >>>> to use BigDecimal.divide with RoundingMode semantics. >>>> >>>> * In SourceCodePanel.java, I settled for suppressing the warning. >>>> The issue here is that modelToView (which returns a Rectangle) is >>>> deprecated in favor of modelToView2D, which returns a Rectangle2D >>>> (which is a supertype of Rectangle). But we use the result in >>>> scrollRectToVisible, and there exist no version of that which >>>> accepts a Rectangle2D instead of a Rectangle, nor a way to created >>>> a Rectangle from a Rectangle2D (that I could find). In practice, >>>> this is just a game of types -- under the hood, modelToView2D still >>>> returns a Rectangle (even though it only promises a Rectangle2D). >>>> The alternative here would be to cast the result of modelToView2D >>>> to a Rectangle, but I found that less attractive. >>>> >>>> * In JTreeTable.java, I've replaced the use of the old-style >>>> modifier mask with the new-style extended modifier mask. To the >>>> best of my understanding, this will just work the same for the code >>>> here (and for the MouseEvent constructor, using the extended mask >>>> is actually prescribed). >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242808 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.01 >>>> >>>> >> From prasanta.sadhukhan at oracle.com Wed Apr 15 12:52:20 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 15 Apr 2020 18:22:20 +0530 Subject: RFR JDK-8226464:TitledBorder label appears cut off on hidpi devices Message-ID: <30e3e728-413c-620a-72bd-a891133832d9@oracle.com> Hi All, Please review a fix for an issue where it is seen that the TitledBorderLabel is cutoff for uiScale>1.25 for SynthLookAndFeel. It is found that in BasicLabelUI, used for other L&Fs,where the issue is not seen, the paint() method calls layout()=>SwingUtilities.layoutCompoundLabel() to get the clipped version of the label string but SynthLabelUI#paint calls SynthGraphicsUtils#paintText which calls layoutText() which also used SwingUtilities.layoutCompoundLabel() to get the clipped version of the label string but still it additionally does its own clipping using text bounds. This bounds is passed in both Basic L&F and Synth L&F via paintEnabledText() and paintText() respectively to SwingUtilities2.drawStringUnderlineCharAt() to drawthe string, so only additional clipping done in SynthL&F is the cause of the problem. Proposed fix is to remove this additional clipping in SynthL&F. Bug: https://bugs.openjdk.java.net/browse/JDK-8226464 webrev: http://cr.openjdk.java.net/~psadhukhan/8226464/webrev.0/ Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Wed Apr 15 13:00:27 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 15 Apr 2020 15:00:27 +0200 Subject: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent In-Reply-To: <194c6cca-f6c5-5250-3dbf-5c03036c3280@oracle.com> References: <4363cce8-1507-f3e5-9e13-d7f96b044d31@oracle.com>

<194c6cca-f6c5-5250-3dbf-5c03036c3280@oracle.com> Message-ID: <7e66a73d-910c-52f7-683b-f6964c4942b2@oracle.com> Here is an updated version, that avoids the SuppressWarnings for modelToView: http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.02 (Only change is in SourceCodePanel.java compared to v01) /Magnus On 2020-04-15 14:30, Magnus Ihse Bursie wrote: > > > On 2020-04-15 12:59, Prasanta Sadhukhan wrote: >> Hi Magnus, >> >> Why can't we just use modelToView2D() to get Rectangle2D and then >> cast to Rectangle tobe used in scrollRectToVisible() or else use >> (int)Rectangle2D.getX(), (int)getY(), getWidth(), getHeight() to >> construct a new Rectangle()? > Casting a Rectangle2D to a Rectangle does not seem to me to be an > improvement. That presupposes even more knowledge about implementation > details. > > However, I'll look into constructing a Rectangle using the getters > from the Rectangle2D, as you suggested. Thanks! > > /Magnus >> >> Regard >> Prasanta >> On 15-Apr-20 3:35 PM, Magnus Ihse Bursie wrote: >>> Hi swing-dev, >>> >>> Do you have any other suggestions for how to resolve the deprecation >>> of modelToView() in this code? >>> >>> Basically, the code does this: >>> >>> ?????? Rectangle rect = source.modelToView(offset); >>> ?????? source.scrollRectToVisible(rect); >>> >>> but scrollRectToVisible() requires a Rectangle (a subtype of >>> Rectangle2D), and modelToView() is deprecated with reference to >>> modelToView2D(), which returns a Rectangle2D, which is thus unusable >>> by scrollRectToVisible(). I also cannot find a way to create a new >>> Rectangle, given a Rectangle2D. >>> >>> In practice, under the hood, it's still just Rectangles (not >>> Rectangle2D). >>> >>> /Magnus >>> >>> On 2020-04-15 11:37, David Holmes wrote: >>>> Hi Magnus, >>>> >>>> This one sounds like it needs a Swing/Java2D developer to review it :) >>>> >>>> Cheers, >>>> David >>>> >>>> On 15/04/2020 7:13 pm, Magnus Ihse Bursie wrote: >>>>> After JDK-8242804, a few places remain which are using deprecated >>>>> methods. They too should be fixed, and the deprecation warning >>>>> should no longer be disabled. >>>>> >>>>> This patch presupposes the fix for JDK-8242804 has been applied >>>>> (otherwise we cannot turn the deprecation warning back on). >>>>> >>>>> Some brief comments about each fix: >>>>> >>>>> * In ConstantPool.java, there was a boxing deprecation that I >>>>> missed in JDK-8242804 (sorry!) >>>>> >>>>> * In HighPrecisionJScrollBar.java, there is a trivial replacement >>>>> to use BigDecimal.divide with RoundingMode semantics. >>>>> >>>>> * In SourceCodePanel.java, I settled for suppressing the warning. >>>>> The issue here is that modelToView (which returns a Rectangle) is >>>>> deprecated in favor of modelToView2D, which returns a Rectangle2D >>>>> (which is a supertype of Rectangle). But we use the result in >>>>> scrollRectToVisible, and there exist no version of that which >>>>> accepts a Rectangle2D instead of a Rectangle, nor a way to created >>>>> a Rectangle from a Rectangle2D (that I could find). In practice, >>>>> this is just a game of types -- under the hood, modelToView2D >>>>> still returns a Rectangle (even though it only promises a >>>>> Rectangle2D). The alternative here would be to cast the result of >>>>> modelToView2D to a Rectangle, but I found that less attractive. >>>>> >>>>> * In JTreeTable.java, I've replaced the use of the old-style >>>>> modifier mask with the new-style extended modifier mask. To the >>>>> best of my understanding, this will just work the same for the >>>>> code here (and for the MouseEvent constructor, using the extended >>>>> mask is actually prescribed). >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242808 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.01 >>>>> >>>>> >>> > From prasanta.sadhukhan at oracle.com Thu Apr 16 03:32:53 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 16 Apr 2020 09:02:53 +0530 Subject: RFR JDK-8226464:TitledBorder label appears cut off on hidpi devices In-Reply-To: <3aa5eaa9-3720-1513-d8b8-08722d3d6af7@oracle.com> References: <30e3e728-413c-620a-72bd-a891133832d9@oracle.com> <3aa5eaa9-3720-1513-d8b8-08722d3d6af7@oracle.com> Message-ID: <805e20b1-3f56-aaa7-4f9d-7809a7d2bfea@oracle.com> Yes, 8075918 fix also works ok with this fix as I can see. Regards Prasanta On 15-Apr-20 10:37 PM, Sergey Bylokhov wrote: > Hi, Prasanta. > > That additional clipping was added as part of JDK-8075918, can you > please confirm that JDK-8075918 fix will not be broken by the current > one. > > On 4/15/20 5:52 am, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that the >> TitledBorderLabel is cutoff for uiScale>1.25 for SynthLookAndFeel. >> >> It is found that in BasicLabelUI, used for other L&Fs,where the issue >> is not seen, the paint() method calls >> layout()=>SwingUtilities.layoutCompoundLabel() to get the clipped >> version of the label string >> >> but SynthLabelUI#paint calls SynthGraphicsUtils#paintText which calls >> layoutText() which also used SwingUtilities.layoutCompoundLabel() to >> get the clipped version of the label string but still it additionally >> does its own clipping using text bounds. >> >> This bounds is passed in both Basic L&F and Synth L&F via >> paintEnabledText() and paintText() respectively to >> SwingUtilities2.drawStringUnderlineCharAt() to drawthe string, so >> only additional clipping done in SynthL&F is the cause of the problem. >> >> Proposed fix is to remove this additional clipping in SynthL&F. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8226464 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8226464/webrev.0/ >> >> Regards >> Prasanta > > From prasanta.sadhukhan at oracle.com Thu Apr 16 10:16:26 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 16 Apr 2020 15:46:26 +0530 Subject: RFR JDK-8232243:Wrong caret position in JTextPane on Windows with a screen resolution > 100% Message-ID: <8bc45f92-3f5e-ba36-8b24-47e0d46dba02@oracle.com> Hi All, Please review a fix for an issue where it is seen that, with a screen resolution higher than 100% and then clicking in a JTextPane, the caret (insertion point) is not aligned with the cursor. The issue seems to stem from the fact that caret position calculation in DefaultCaret class utilises API that uses integer calculation than floating point calculations. This issue is in continuation to the fix done for JDK-8199441 where the issue was fixed for JTextArea. [http://hg.openjdk.java.net/jdk/jdk/rev/480c2ae4d031] The code flow for JTextArea was DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset whereas for JTextPane it it is DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>GlyphPainter1#viewToModel=>Utilities.getTabbedOffset Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses integer arithmetic to get the caret position. The same getTabbedOffset uses Font.getStringBounds() which uses floating point arithmetic via Rectangle2D.Float. Proposed fix is to make sure proper floating point getTabbedOffset API is used so that floating point calculations is done for char width. Bug:https://bugs.openjdk.java.net/browse/JDK-8232243 webrev: http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.0/ Regards Prasanta From Sergey.Bylokhov at oracle.com Thu Apr 16 11:14:08 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 Apr 2020 04:14:08 -0700 Subject: RFR JDK-8226464:TitledBorder label appears cut off on hidpi devices In-Reply-To: <805e20b1-3f56-aaa7-4f9d-7809a7d2bfea@oracle.com> References: <30e3e728-413c-620a-72bd-a891133832d9@oracle.com> <3aa5eaa9-3720-1513-d8b8-08722d3d6af7@oracle.com> <805e20b1-3f56-aaa7-4f9d-7809a7d2bfea@oracle.com> Message-ID: <3550ed7c-881b-1686-2047-e8763fe9dae1@oracle.com> Looks fine. On 4/15/20 8:32 pm, Prasanta Sadhukhan wrote: > Yes, 8075918 fix also works ok with this fix as I can see. > > Regards > Prasanta > On 15-Apr-20 10:37 PM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> >> That additional clipping was added as part of JDK-8075918, can you please confirm that JDK-8075918 fix will not be broken by the current one. >> >> On 4/15/20 5:52 am, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that the TitledBorderLabel is cutoff for uiScale>1.25 for SynthLookAndFeel. >>> >>> It is found that in BasicLabelUI, used for other L&Fs,where the issue is not seen, the paint() method calls layout()=>SwingUtilities.layoutCompoundLabel() to get the clipped version of the label string >>> >>> but SynthLabelUI#paint calls SynthGraphicsUtils#paintText which calls layoutText() which also used SwingUtilities.layoutCompoundLabel() to get the clipped version of the label string but still it additionally does its own clipping using text bounds. >>> >>> This bounds is passed in both Basic L&F and Synth L&F via paintEnabledText() and paintText() respectively to SwingUtilities2.drawStringUnderlineCharAt() to drawthe string, so only additional clipping done in SynthL&F is the cause of the problem. >>> >>> Proposed fix is to remove this additional clipping in SynthL&F. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8226464 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8226464/webrev.0/ >>> >>> Regards >>> Prasanta >> >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Apr 16 11:18:10 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 Apr 2020 04:18:10 -0700 Subject: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue In-Reply-To: References:

<4cfd1bd2-0a45-4b23-97a3-e1a773db1785@default>

<75808EB0-5C20-4698-92F1-D14A3619E676@sap.com> <27f5dd3f-0d31-0690-1ea2-8277e8f969cf@oracle.com> <65102afd-0078-12cd-7a17-24a9b27548aa@oracle.com> <785ec7c7-efa5-56f0-b695-734f174be49c@oracle.com> <3a4a2cb9-4735-405b-ba6d-6e30131f70b5@default> <30730877-5548-46fb-8b8c-716f3b239ba0@default> <0D81D11D-910C-4B0F-AF02-E3D768F21D6C@sap.com> <67d61ba9-0f42-31d6-e03d-2e715df67c77@oracle.com> Message-ID: On 4/7/20 9:18 am, Pankaj Bansal wrote: > << Probably I missed the point but isn't it too many changes for this? > < < Most of these changes are needed to support changing the value from text field directly instead of up/down button. Changing from textfield can change min/max allowed etc. Ok, can we split the change related to setting the data via text field from the change of iteration over the number of steps using count? I think it could be fixed separately. > > Regards, > Pankaj > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, April 7, 2020 9:46 PM > To: Pankaj Bansal ; Volodin, Vladislav > Cc: swing-dev at openjdk.java.net; Jason Mehrens ; Alexey Ivanov > Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue > > Probably I missed the point but isn't it too many changes for this? > > Number base, expectedNewValue, newMinimum, newMaximum; int currentStep, positeveCount, negativeCount; > > I expected that we will have only one new "count" field, probably all changes are needed, I'll check closely. > > On 4/7/20 9:01 am, Pankaj Bansal wrote: >> I tried few things and I think this version is working fine. I tested this version with few tests and this seem to work in all cases. Please have a look. > > The test from the first version of the fix missed? > >> >> webrev: http://cr.openjdk.java.net/~pbansal/8220811/webrev02/ >> >> Regards, >> Pankaj >> >> -----Original Message----- >> From: Volodin, Vladislav >> Sent: Sunday, March 15, 2020 2:03 AM >> To: Pankaj Bansal >> Cc: swing-dev at openjdk.java.net; Jason Mehrens >> ; Sergey Bylokhov >> ; Alexey Ivanov >> Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel >> floating point rounding issue >> >> Hello Pankaj, >> >> I am not the reviewer, but I agree with Jason. To me p1.equals(Double.NaN) looks confusing. Because people might think that it will be equivalent to p1 == Double.NaN, that will return false, when p1 is also NaN (https://urldefense.com/v3/__https://stackoverflow.com/questions/8819738/why-does-double-nan-double-nan-return-false__;!!GqivPVa7Brio!MCTIuSS1NcMZWK7ZWOAVUhgC-AoVMYwCGbgTiDOH5pO2PQfW7b7XN-hLRtqBuhi6XnVl$ ). >> I prefer to use the dedicated method such as "public static boolean isNaN(double v)". It looks self-descriptive. >> >> Meanwhile, I remember you sentence regarding the number of steps: >> > double min=-.15,max=0.15,stepsize=.05, the steps is calculated as 5. double min=-.15,max=0.20,stepsize=.05, the steps is calculated as 7 instead of 6. >> I checked this part with the code: >> >> Double min = -.15; >> Double max = 0.15; >> Double stepsize = .05; >> Double steps = (max - min) / stepsize; >> >> And I found out that in this case the number of steps will be 5,999999....., but we can compensate it with either Math.round, it will return 6, or we can add the "epsilon" value to "max", and count the number of steps as it is: >> Double max = 0.15 + Math.ulp(1.0); Steps count will be 6.00000238418579. >> >> Since there is no value in Double (and probably float) less than Math.ulp (or epsilon, if we use this term), it will be probably safe to use my approach. What do you think? >> >> Kind regards, >> Vlad >> >> ?On 14.03.20, 15:51, "Pankaj Bansal" wrote: >> >> Hello Jason, >> >> << I would assume newMinimum.equals(Double.NaN) and newMinimum.equals(Float.NaN) should always evaluate to false. >> It seems to work as expected. >> Double p1 = Double.NaN; >> Double p2 = 1.0; >> System.out.println(p1.equals(Double.NaN)); //prints true >> System.out.println(p2.equals(Double.NaN)); //prints false >> >> Regards, >> Pankaj >> >> -----Original Message----- >> From: Jason Mehrens >> Sent: Saturday, March 14, 2020 8:09 PM >> To: Pankaj Bansal ; Sergey Bylokhov ; Alexey Ivanov ; Volodin, Vladislav >> Cc: swing-dev at openjdk.java.net >> Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel >> floating point rounding issue >> >> Pankaj, >> >> I would assume newMinimum.equals(Double.NaN) and newMinimum.equals(Float.NaN) should always evaluate to false. Perhaps you want to use Float.isNaN and Double.isNaN instead? >> >> Jason >> >> ________________________________________ >> From: swing-dev on behalf of Pankaj Bansal >> Sent: Saturday, March 14, 2020 8:11 AM >> To: Sergey Bylokhov; Alexey Ivanov; Volodin, Vladislav >> Cc: swing-dev at openjdk.java.net >> Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel >> floating point rounding issue >> >> Hello Sergey, >> >> << It will differ for two cases: >> - The error will not be accumulated when the counter will move forward/backward, currently the result might different on each iteration. >> - Initial/Default value will never be skipped due to counter=0 >> >> I tried to code according to my understanding of the idea. I have created a preliminary webrev to demonstrate what I am doing. This is nowhere final, so please ignore the optimizations. Please have a look. >> As I was thinking, the precision error is creating issue while creating the step count. I have to do lot of stuff to allow values to be changed by editing the textfield. There are some other issues also, like the double value is formatted according to the formatter and that is also causing problems. >> >> webrev: http://cr.openjdk.java.net/~pbansal/8220811/webrev01/ >> >> Regards, >> Pankaj >> >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Wednesday, March 11, 2020 5:33 AM >> To: Pankaj Bansal ; Alexey Ivanov ; Volodin, Vladislav >> Cc: swing-dev at openjdk.java.net >> Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel >> floating point rounding issue >> >> On 3/10/20 5:34 am, Pankaj Bansal wrote: >> > Hello Sergey/Vlad/Alexey, >> > >> > Sorry, I could not reply to this earlier. I have one doubt about this approach. Won't the calculation of stepCount itself suffer from floating point issue? I mean the user will pass min, max, stepsize, then wont the calculation of steps required to go from min to max will also suffer from same floating point issue? I think there can be an rounding of error of -1 or +1 in calculation of step count. >> >> It will differ for two cases: >> - The error will not be accumulated when the counter will move forward/backward, currently the result might different on each iteration. >> - Initial/Default value will never be skipped due to counter=0 >> >> > >> > eg. >> > >> > int steps =0; >> > >> > for (double i=min+stepsize; i<=max; i+=stepsize) >> > steps++; >> > >> > double min=-.15,max=0.15,stepsize=.05, the steps is calculated as 5. double min=-.15,max=0.20,stepsize=.05, the steps is calculated as 7 instead of 6. >> > >> > >> > The reason is that, there is floating point error in first case, but it is not present in second case. >> > >> > I think the best we can do here is as Sergey suggested in his first >> > reply to use Math.fma to reduce the floating point error chances from >> > 2 to 1 or just close this as not an issue >> > >> > Regards, >> > >> > Pankaj >> > >> > >> > On 19/02/20 3:49 AM, Sergey Bylokhov wrote: >> >> I think it should work, the step will counts from the default value. >> >> >> >> So currently: >> >> 1. if the user set default value to X1 and then he iterates forward 100 times then he will get some X2. During this calculation, he could get "100" rounding issues. >> >> 2. If later the user decides iterates backward then most probably he will not get X1, and the amount of possible "rounding issues" will be 200. >> >> >> >> If the user will repeat steps 1. and 2. then each time the values will "float". >> >> >> >> If we will use counter then in the worst case we will get only two roundings per step: X1+step*100 = X2(if we will use fma we will get only one for every step). >> >> >> >> It will not solve all issues but at least will make the iteration "stable". >> >> >> >> On 2/17/20 1:59 am, Alexey Ivanov wrote: >> >>> Hi Vlad, >> >>> >> >>> The idea looks reasonable. However, it does not allow for manual editing. The cases where max and min values are not multiples of step would be hard to handle with this approach. For example: max = 10.05, min = 0.01, step = 0.1; how many ticks are there? What if the user enters 1.01015; the value should change to 1.11015 or 0.91015. >> >>> >> >>> On 13/02/2020 22:22, Volodin, Vladislav wrote: >> >>>> Hello Sergey, Alexey and Pankaj, >> >>>> >> >>>> I am reading the current discussion and I was thinking about an idea changing the code in the way that instead of working with float/double numbers we work with integer ticks. For example, the model remembers the min/max/step values and calculates a number of steps required to reach from min to max. All increment/decrement actions are done against the current ?tick? value. If the current ?tick? reaches 0 - we return min; if maxTick ? we return max. And the current value can be always counted as (min + tick * step) if tick is neither zero, nor max tick count. >> >>>> >> >>>> At least if we deal with integer ticks, but all reading operations calculate on the fly, we will be able to control the representativeness of output. >> >>>> >> >>>> As always, I don?t know all the details and possible consequences, so feel free to ignore my email, if I am wrong. >> >>>> >> >>>> Kind regards, >> >>>> Vlad >> >>>> >> >>>> Sent from myPad >> >>>> >> >>>>> On 13. Feb 2020, at 22:34, Sergey Bylokhov wrote: >> >>>>> >> >>>>> On 2/12/20 8:21 am, Alexey Ivanov wrote: >> >>>>>> The bug report says that going from -0.15 to -0.10 does not allow going back to -0.15. This happens because the result of this sequence of operations cannot be represented exactly, or, in other words, because of rounding errors; or rather the result is less than the set minimal value. >> >>>>>> Can we set the value of the spinner to the set minimal value instead of disallowing the operation. I mean, after going up the displayed value is -0.10; going down by 0.05 gives the result which is less than the minimal value for the spinner, and thus going down is not allowed. What if we set the value of the spinner to its minimal value instead? >> >>>>> In this case, we will need to update all types including int. >> >>>>> Isn't it will be surprised that the spinner will show the value which is not calculated as "defaultValue + stepValue * stepCount"? >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Best regards, Sergey. >> >> >> >> >> > >> >> >> -- >> Best regards, Sergey. >> >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From serguei.spitsyn at oracle.com Thu Apr 16 06:15:38 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Apr 2020 23:15:38 -0700 Subject: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent In-Reply-To: <7e66a73d-910c-52f7-683b-f6964c4942b2@oracle.com> References: <4363cce8-1507-f3e5-9e13-d7f96b044d31@oracle.com> <194c6cca-f6c5-5250-3dbf-5c03036c3280@oracle.com> <7e66a73d-910c-52f7-683b-f6964c4942b2@oracle.com> Message-ID: <6a4ed2c8-61ee-3199-adb6-e17f0e87b181@oracle.com> Hi Magnus, It looks good to me. Thanks, Serguei On 4/15/20 06:00, Magnus Ihse Bursie wrote: > Here is an updated version, that avoids the SuppressWarnings for > modelToView: > > http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.02 > > > (Only change is in SourceCodePanel.java compared to v01) > > /Magnus > > On 2020-04-15 14:30, Magnus Ihse Bursie wrote: >> >> >> On 2020-04-15 12:59, Prasanta Sadhukhan wrote: >>> Hi Magnus, >>> >>> Why can't we just use modelToView2D() to get Rectangle2D and then >>> cast to Rectangle tobe used in scrollRectToVisible() or else use >>> (int)Rectangle2D.getX(), (int)getY(), getWidth(), getHeight() to >>> construct a new Rectangle()? >> Casting a Rectangle2D to a Rectangle does not seem to me to be an >> improvement. That presupposes even more knowledge about >> implementation details. >> >> However, I'll look into constructing a Rectangle using the getters >> from the Rectangle2D, as you suggested. Thanks! >> >> /Magnus >>> >>> Regard >>> Prasanta >>> On 15-Apr-20 3:35 PM, Magnus Ihse Bursie wrote: >>>> Hi swing-dev, >>>> >>>> Do you have any other suggestions for how to resolve the >>>> deprecation of modelToView() in this code? >>>> >>>> Basically, the code does this: >>>> >>>> ?????? Rectangle rect = source.modelToView(offset); >>>> ?????? source.scrollRectToVisible(rect); >>>> >>>> but scrollRectToVisible() requires a Rectangle (a subtype of >>>> Rectangle2D), and modelToView() is deprecated with reference to >>>> modelToView2D(), which returns a Rectangle2D, which is thus >>>> unusable by scrollRectToVisible(). I also cannot find a way to >>>> create a new Rectangle, given a Rectangle2D. >>>> >>>> In practice, under the hood, it's still just Rectangles (not >>>> Rectangle2D). >>>> >>>> /Magnus >>>> >>>> On 2020-04-15 11:37, David Holmes wrote: >>>>> Hi Magnus, >>>>> >>>>> This one sounds like it needs a Swing/Java2D developer to review >>>>> it :) >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 15/04/2020 7:13 pm, Magnus Ihse Bursie wrote: >>>>>> After JDK-8242804, a few places remain which are using deprecated >>>>>> methods. They too should be fixed, and the deprecation warning >>>>>> should no longer be disabled. >>>>>> >>>>>> This patch presupposes the fix for JDK-8242804 has been applied >>>>>> (otherwise we cannot turn the deprecation warning back on). >>>>>> >>>>>> Some brief comments about each fix: >>>>>> >>>>>> * In ConstantPool.java, there was a boxing deprecation that I >>>>>> missed in JDK-8242804 (sorry!) >>>>>> >>>>>> * In HighPrecisionJScrollBar.java, there is a trivial replacement >>>>>> to use BigDecimal.divide with RoundingMode semantics. >>>>>> >>>>>> * In SourceCodePanel.java, I settled for suppressing the warning. >>>>>> The issue here is that modelToView (which returns a Rectangle) is >>>>>> deprecated in favor of modelToView2D, which returns a Rectangle2D >>>>>> (which is a supertype of Rectangle). But we use the result in >>>>>> scrollRectToVisible, and there exist no version of that which >>>>>> accepts a Rectangle2D instead of a Rectangle, nor a way to >>>>>> created a Rectangle from a Rectangle2D (that I could find). In >>>>>> practice, this is just a game of types -- under the hood, >>>>>> modelToView2D still returns a Rectangle (even though it only >>>>>> promises a Rectangle2D). The alternative here would be to cast >>>>>> the result of modelToView2D to a Rectangle, but I found that less >>>>>> attractive. >>>>>> >>>>>> * In JTreeTable.java, I've replaced the use of the old-style >>>>>> modifier mask with the new-style extended modifier mask. To the >>>>>> best of my understanding, this will just work the same for the >>>>>> code here (and for the MouseEvent constructor, using the extended >>>>>> mask is actually prescribed). >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242808 >>>>>> WebRev: >>>>>> http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.01 >>>>>> >>>>>> >>>> >> > From Sergey.Bylokhov at oracle.com Thu Apr 16 11:23:19 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 Apr 2020 04:23:19 -0700 Subject: RFR JDK-8233644, , [TESTBUG] JInternalFrame test bug8020708.java is failing on macos In-Reply-To: References: Message-ID: <8d6aed85-9ef0-9951-1816-b1b06b849551@oracle.com> Looks fine. On 4/13/20 11:47 am, Prasanta Sadhukhan wrote: > Hi All, > > The fix done for "8242526: PIT: javax/swing/JInternalFrame/8020708/bug8020708.java fails in mach5 ubuntu system" works for macOS too, so we can remove the test from ProblemList. > > Testing for 100 iterations on mach5 mac system works ok (link in JBS) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233644 > > diff -r 19afeaa0fdbe test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt? Sat Apr 11 10:32:17 2020 +0530 > +++ b/test/jdk/ProblemList.txt? Mon Apr 13 23:58:32 2020 +0530 > @@ -886,7 +886,6 @@ > ?javax/swing/JMenuBar/4750590/bug4750590.java 8233642 macosx-all > ?javax/swing/JMenu/4692443/bug4692443.java 8171998 macosx-all > ?javax/swing/JMenu/4515762/bug4515762.java 8233643 macosx-all > *-javax/swing/JInternalFrame/8020708/bug8020708.java 8233644 macosx-all* > ?javax/swing/JColorChooser/Test8051548.java 8233647 macosx-all > ?javax/swing/plaf/synth/7158712/bug7158712.java 8238720 windows-all > > Regards > Prasanta -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Apr 16 11:28:34 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 16 Apr 2020 04:28:34 -0700 Subject: RFR JDK-8242410: JEditorPane with test/html type and zero margins is not shown In-Reply-To: <270d702e-87b1-4f68-a273-d5446af7d520@oracle.com> References: <270d702e-87b1-4f68-a273-d5446af7d520@oracle.com> Message-ID: <789b853e-b2df-82fb-96c9-b5836728c4b0@oracle.com> Hi, Prasanta. Remembering the number of regressions caused by the changes in this method, I suggest to improve it by some additional code only when we investigate the root cause of all previous issues. The general approach of using zeros as non-initialized flags seems broken. On 4/13/20 3:06 am, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that when JEditorPane is created with empty text and zero top and bottom insets, the text is not shown after updating it by the method setText(String) > > This is because the the JEditorPane height is not updated and remains 0 if the margin top/botton insets are 0. > > Proposed fix is to check if the margin being set is less than default margin, then update the margin to the default. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242410 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8242410/webrev.0/ > > I also considered changing getPreferredSize() to update the rootView size if height is 0, but it seems it has caused some regression in the past, so abstained from that > > /-else if (d.width == 0 && d.height == 0) {/ > /+//else if (d.width == 0 || d.height == 0) {/ > > /??????????????? // Probably haven't been layed out yet, force some sort of// > //??????????????? // initial sizing.// > //??????????????? rootView.setSize(Integer.MAX_VALUE, Integer.MAX_VALUE);// > //??????????? }/ > > Regards > Prasanta -- Best regards, Sergey. From JAYATHIRTH.D.V at ORACLE.COM Thu Apr 16 11:41:42 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Thu, 16 Apr 2020 17:11:42 +0530 Subject: RFR JDK-8213123:javax/swing/JButton/4368790/bug4368790.java fails on mac In-Reply-To: References: <05b545c2-2519-1677-2646-43b5d8ed8159@oracle.com> <1155d852-9cd5-8c14-7065-4da56c788ae0@oracle.com> Message-ID: +1. Thanks, Jay > On 09-Apr-2020, at 5:05 PM, Sergey Bylokhov wrote: > > Looks fine. > > On 4/8/20 10:14 pm, Prasanta Sadhukhan wrote: >> Yes, other L&F does not have this bug as confirmed by updated test testing all installed L&Fs >> http://cr.openjdk.java.net/~psadhukhan/8213123/webrev.1/ >> Regards >> Prasanta >> On 09-Apr-20 2:08 AM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> >>> Could you confirm that other non-default L&F does not have this bug, probably it would be good to check that in the test? >>> >>> >>> On 4/8/20 5:17 am, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue where it is seen that in macOS, JButton remains pressed even when the focus is lost. >>>> >>>> This was fixed inJDK-4368790: JButton stays pressed when focus stolen by calling setPressed(false) for BasicButtonListener created in BasicButtonUI#installListener for other L&Fs, but it fails for default AquaL&F in macOS. >>>> >>>> The same needs to be done in AquaButtonListener created in AquaButtonUI#installListener for mac >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213123 >>>> >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8213123/webrev.0/ >>>> >>>> Regards >>>> Prasanta >>> >>> > > > -- > Best regards, Sergey. From JAYATHIRTH.D.V at ORACLE.COM Thu Apr 16 12:22:45 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Thu, 16 Apr 2020 17:52:45 +0530 Subject: RFR JDK-8233644, , [TESTBUG] JInternalFrame test bug8020708.java is failing on macos In-Reply-To: <8d6aed85-9ef0-9951-1816-b1b06b849551@oracle.com> References: <8d6aed85-9ef0-9951-1816-b1b06b849551@oracle.com> Message-ID: <73493FBB-C4BE-48D1-860A-90EB5B0E9AE4@ORACLE.COM> +1. Thanks, Jay > On 16-Apr-2020, at 4:53 PM, Sergey Bylokhov wrote: > > Looks fine. > > On 4/13/20 11:47 am, Prasanta Sadhukhan wrote: >> Hi All, >> The fix done for "8242526: PIT: javax/swing/JInternalFrame/8020708/bug8020708.java fails in mach5 ubuntu system" works for macOS too, so we can remove the test from ProblemList. >> Testing for 100 iterations on mach5 mac system works ok (link in JBS) >> Bug: https://bugs.openjdk.java.net/browse/JDK-8233644 >> diff -r 19afeaa0fdbe test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt Sat Apr 11 10:32:17 2020 +0530 >> +++ b/test/jdk/ProblemList.txt Mon Apr 13 23:58:32 2020 +0530 >> @@ -886,7 +886,6 @@ >> javax/swing/JMenuBar/4750590/bug4750590.java 8233642 macosx-all >> javax/swing/JMenu/4692443/bug4692443.java 8171998 macosx-all >> javax/swing/JMenu/4515762/bug4515762.java 8233643 macosx-all >> *-javax/swing/JInternalFrame/8020708/bug8020708.java 8233644 macosx-all* >> javax/swing/JColorChooser/Test8051548.java 8233647 macosx-all >> javax/swing/plaf/synth/7158712/bug7158712.java 8238720 windows-all >> Regards >> Prasanta > > > -- > Best regards, Sergey. From bhawesh.choudhary at oracle.com Fri Apr 17 06:44:20 2020 From: bhawesh.choudhary at oracle.com (Bhawesh Choudhary) Date: Fri, 17 Apr 2020 12:14:20 +0530 Subject: RFR: 8233584: [Win LAF] When navigating the contents of the file list changes in Win LAF In-Reply-To: References: <60d5b758-df58-9ba7-04a4-1603fa205263@oracle.com> <33cfebf6-2eac-ea58-781b-d8c0283cda4a@oracle.com> <3e20ef5a-6549-0a8e-d017-fc71bff92de6@oracle.com> Message-ID: <9d7be300-667a-5528-f8c5-8b8e2ac0b9cc@oracle.com> Hi Alexey, Please review below fix updated as per your suggestion. -Bhawesh On 4/6/2020 12:22 PM, Bhawesh Choudhary wrote: > Hi Alexey, > > Please find updated Webrev as per suggestion. I couldn't make test > automatic due to not able to read contents currently being displayed > in JFileChooser. > > JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 > Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.2/ > > -Bhawesh > > On 4/2/2020 12:17 AM, Alexey Ivanov wrote: >> Hi Bhawesh, >> >> Shall we add >> @requires |os.family == "windows" >> to the test? Then it won't be even selected for running by jtreg. >> >> It think the copyright year should be updated in both modified files, >> should it? >> >> I'd also suggest using explicit import statements for javax.swing.* >> classes instead of the wildcard one. >> >> Is it possible to make the automatic? However, this is out of scope >> of this bug. >> >> >> Regards, >> Alexey >> | >> On 31/03/2020 10:16, Bhawesh Choudhary wrote: >>> Hi, >>> >>> Please find updated Webrev as per suggestions [Test case updates for >>> WindowsLookAndFeel] >>> >>> JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 >>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.1/ >>> >>> -Bhawesh >>> >>> On 3/13/2020 12:10 PM, Bhawesh Choudhary wrote: >>>> Hi, >>>> >>>> Please find updated Webrev as per suggestions [Test name update and >>>> Code formatting] >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.01/ >>>> >>>> -Bhawesh >>>> >>>> On 3/4/2020 4:13 PM, Bhawesh Choudhary wrote: >>>>> Hi, >>>>> >>>>> Please review this fix, >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev/ >>>>> >>>>> Issue: >>>>> In Windows LookAndFeel, When navigating Combobox's list of >>>>> JFileChooser via keys, the contents of JFileChooser changes. >>>>> >>>>> Fix: >>>>> Set flag "JComboBox.isTableCellEditor" to True which prohibits >>>>> JCombobox from sending selection change event when JCombobox's >>>>> list selection change happens via keys. >>>>> >>>>> >>>>> Verification: >>>>> Tested the fix with JFileChooser with WindowsLookAndFeelEnabled as >>>>> well as BasicLookAndFeel with keys navigation. also added a test >>>>> case to verify the same. >>>>> >>>>> Did not find any misbehavior with the fix. >>>>> >>>>> Regards >>>>> Bhawesh > From prasanta.sadhukhan at oracle.com Fri Apr 17 11:16:48 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 17 Apr 2020 16:46:48 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <23ffdef1-4dd2-7820-a57d-d4f6410302bf@oracle.com> <8757e954-b413-a68f-a6d7-7b2fd66cb6e1@oracle.com> <260266da-9c2d-ebb8-6af0-58bcf6162e04@oracle.com> <5c8527be-d47f-7052-124d-361b21b26e49@oracle.com> <3e37c6d4-4ddb-a829-7504-b2afd92b6996@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> Message-ID: <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> On 15-Apr-20 5:11 PM, Sergey Bylokhov wrote: > On 4/6/20 5:07 am, Prasanta Sadhukhan wrote: >> >> ????????????? tip = insideComponent.createToolTip(); >> ????????????? tip.setTipText(toolTipText); >> + >> +??????????? System.out.println("default gc " + >> gc.getDefaultTransform()); >> +??????????? System.out.println("insideComponent GC " + >> insideComponent.getGraphicsConfiguration().getDefaultTransform()); >> +??????????? GraphicsConfiguration oldConfig = >> tip.getGraphicsConfiguration(); >> +??????????? System.out.println("tip oldgc " + >> tip.getGraphicsConfiguration()); >> +??????????? GraphicsConfiguration newConfig = >> tip.getGraphicsConfiguration(); >> +??????????? if (newConfig == null) { >> +??????????????? newConfig = >> GraphicsEnvironment.getLocalGraphicsEnvironment(). >> + getDefaultScreenDevice().getDefaultConfiguration(); >> +??????????? } >> +??????????? System.out.println("newgc " + newConfig); >> +??????????? if (newConfig != null) System.out.println(" transform " >> + newConfig.getDefaultTransform()); >> +??????????? tip.firePropertyChange("graphicsConfiguration", >> oldConfig, newConfig); >> + >> + >> ????????????? size = tip.getPreferredSize(); >> +??????????? System.out.println("tip preferredsize " + size); > > I think it is necessary to inject the "insideComponent"'s GC to the > tip somewhere in the .createToolTip() and use this GC by default in > the tip, for the test we can try to override > getGraphicsConfiguration() in tip and return > component.getGraphicsConfiguration(). > > BTW did you notice that in the test when the size of the frame are > changed from bigger to smaller by the "space" key the tooltip usually > cut as well? Probably we need to change the type of the tip on the > fly? from LW to HW? Thanks for the suggestion. This approach of setting HW popup is more cleaner than 1st as there is no public setGraphicsConfiguration() to be used to set tip's GC with inideComponent's GC. Also, the popupType will remain LW as we are only using it to create the tip but doing setPopupType() to LW after tooltip popup creation. http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.3/ Regards Prasanta From prasanta.sadhukhan at oracle.com Fri Apr 17 15:04:19 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 17 Apr 2020 20:34:19 +0530 Subject: RFR JDK-8178028: Typing 'C' cannot change the tab layout to WRAP_TAB_LAYOUT Message-ID: <3383c21c-36b8-a84d-59d5-09f1cba146c4@oracle.com> Hi All, Please review a test fix for an issue where it is seen that JTabbedPane tabLayoutPolicy was not getting changed from SCROLL_TAB_LAYOUT to WRAP_TAB_LAYOUT. This is because the test creates only 5 tabs which fits on the window whereas the JTabbedPane.WRAP_TAB_LAYOUT spec says "The tab layout policy for wrapping tabs in multiple runs when all tabs will not fit within a single run" so I fixed it by creating multiple tabs which will not fit on screen, so now toggling between SCROLL_TAB_LAYOUT and WRAP_TAB_LAYOUT policy causes the tabs to either show only subset of tabs or wrap tabs into multiple lines respectively. Also, the subtest of typing "C" to test WRAP_TAB_LAYOUT policy is moved to 1st subtest as currently the test is after "L" which is LEFT tab placement so the tabs will be aligned vertically, which will again cause the tabs to fit on window, causing *TAB_LAYOUT policy to not work. Bug: https://bugs.openjdk.java.net/browse/JDK-8178028 webrev: http://cr.openjdk.java.net/~psadhukhan/8178028/webrev.0/ Regards Prasanta From Sergey.Bylokhov at oracle.com Sun Apr 19 15:22:26 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 19 Apr 2020 08:22:26 -0700 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <23ffdef1-4dd2-7820-a57d-d4f6410302bf@oracle.com> <8757e954-b413-a68f-a6d7-7b2fd66cb6e1@oracle.com> <260266da-9c2d-ebb8-6af0-58bcf6162e04@oracle.com> <5c8527be-d47f-7052-124d-361b21b26e49@oracle.com> <3e37c6d4-4ddb-a829-7504-b2afd92b6996@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> Message-ID: On 4/17/20 4:16 am, Prasanta Sadhukhan wrote: > Also, the popupType will remain LW as we are only using it to create the tip but doing setPopupType() to LW after tooltip popup creation. > > http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.3/ This is equivalent to using HW tooltip every time on the HiDPI screen, and unfortunately it has a side effect. If the tooltip is HW it is drawn in a separate window and is not inherit opacity/translucency of the parent, you can check that by these changes in the test: frame.setLocationRelativeTo(null); +frame.setUndecorated(true); +frame.setOpacity(.5f); frame.setVisible(true); I still think that using right GC in the tip, is probably better way to fix it. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Apr 20 09:40:56 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 20 Apr 2020 15:10:56 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <23ffdef1-4dd2-7820-a57d-d4f6410302bf@oracle.com> <8757e954-b413-a68f-a6d7-7b2fd66cb6e1@oracle.com> <260266da-9c2d-ebb8-6af0-58bcf6162e04@oracle.com> <5c8527be-d47f-7052-124d-361b21b26e49@oracle.com> <3e37c6d4-4ddb-a829-7504-b2afd92b6996@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> Message-ID: <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> On 19-Apr-20 8:52 PM, Sergey Bylokhov wrote: > On 4/17/20 4:16 am, Prasanta Sadhukhan wrote: >> Also, the popupType will remain LW as we are only using it to create >> the tip but doing setPopupType() to LW after tooltip popup creation. >> >> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.3/ > > This is equivalent to using HW tooltip every time on the HiDPI screen, > and unfortunately it has a side effect. > > If the tooltip is HW it is drawn in a separate window and is not > inherit opacity/translucency of the parent, > you can check that by these changes in the test: > ??? frame.setLocationRelativeTo(null); > ?? +frame.setUndecorated(true); > ?? +frame.setOpacity(.5f); > ??? frame.setVisible(true); > > I still think that using right GC in the tip, is probably better way > to fix it. > http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.4/ used the right GC for the tip but we still need the preferredSize in the paint() Regards Prasanta From Sergey.Bylokhov at oracle.com Mon Apr 20 15:24:43 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 20 Apr 2020 08:24:43 -0700 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <8757e954-b413-a68f-a6d7-7b2fd66cb6e1@oracle.com> <260266da-9c2d-ebb8-6af0-58bcf6162e04@oracle.com> <5c8527be-d47f-7052-124d-361b21b26e49@oracle.com> <3e37c6d4-4ddb-a829-7504-b2afd92b6996@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> Message-ID: <7ee86f9f-9b63-ec34-6c42-189661dda3fd@oracle.com> On 4/20/20 2:40 am, Prasanta Sadhukhan wrote: > http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.4/ > > used the right GC for the tip but we still need the preferredSize in the paint() Why do we need it? Do we calculate the size in the ToolTipManager.showTipWindow() incorrectly? We call tip.getPreferredSize() there, does it return different result than in the paint() method? -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Apr 20 15:34:42 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 20 Apr 2020 21:04:42 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <7ee86f9f-9b63-ec34-6c42-189661dda3fd@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <260266da-9c2d-ebb8-6af0-58bcf6162e04@oracle.com> <5c8527be-d47f-7052-124d-361b21b26e49@oracle.com> <3e37c6d4-4ddb-a829-7504-b2afd92b6996@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> <7ee86f9f-9b63-ec34-6c42-189661dda3fd@oracle.com> Message-ID: <8a676287-9aed-df8b-4638-c6f809e1336f@oracle.com> On 20-Apr-20 8:54 PM, Sergey Bylokhov wrote: > On 4/20/20 2:40 am, Prasanta Sadhukhan wrote: >> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.4/ >> >> used the right GC for the tip but we still need the preferredSize in >> the paint() > > Why do we need it? Do we calculate the size in the > ToolTipManager.showTipWindow() incorrectly? > We call tip.getPreferredSize() there,? does it return different result > than in the paint() method? > No, there it returns the same value as paint() now after GC fix, but c.getSize() in paint() returns the JPanel size which is not same as preferredSize and it is not enough to contain the text, it seems. From Sergey.Bylokhov at oracle.com Mon Apr 20 16:46:45 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 20 Apr 2020 09:46:45 -0700 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <8a676287-9aed-df8b-4638-c6f809e1336f@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <5c8527be-d47f-7052-124d-361b21b26e49@oracle.com> <3e37c6d4-4ddb-a829-7504-b2afd92b6996@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> <7ee86f9f-9b63-ec34-6c42-189661dda3fd@oracle.com> <8a676287-9aed-df8b-4638-c6f809e1336f@oracle.com> Message-ID: <8f3179d4-410a-0cc7-61e4-9773b05e6b43@oracle.com> On 4/20/20 8:34 am, Prasanta Sadhukhan wrote: > > On 20-Apr-20 8:54 PM, Sergey Bylokhov wrote: >> On 4/20/20 2:40 am, Prasanta Sadhukhan wrote: >>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.4/ >>> >>> used the right GC for the tip but we still need the preferredSize in the paint() >> >> Why do we need it? Do we calculate the size in the ToolTipManager.showTipWindow() incorrectly? >> We call tip.getPreferredSize() there,? does it return different result than in the paint() method? >> > No, there it returns the same value as paint() now after GC fix, but c.getSize() in paint() returns the JPanel size which is not same as preferredSize and it is not enough to contain the text, it seems. But the panel and window both are created by our code in ToolTipManager.showTipWindow, should we adjust it? -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Apr 20 16:50:25 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 20 Apr 2020 22:20:25 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <8f3179d4-410a-0cc7-61e4-9773b05e6b43@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <5c8527be-d47f-7052-124d-361b21b26e49@oracle.com> <3e37c6d4-4ddb-a829-7504-b2afd92b6996@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> <7ee86f9f-9b63-ec34-6c42-189661dda3fd@oracle.com> <8a676287-9aed-df8b-4638-c6f809e1336f@oracle.com> <8f3179d4-410a-0cc7-61e4-9773b05e6b43@oracle.com> Message-ID: On 20-Apr-20 10:16 PM, Sergey Bylokhov wrote: > On 4/20/20 8:34 am, Prasanta Sadhukhan wrote: >> >> On 20-Apr-20 8:54 PM, Sergey Bylokhov wrote: >>> On 4/20/20 2:40 am, Prasanta Sadhukhan wrote: >>>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.4/ >>>> >>>> used the right GC for the tip but we still need the preferredSize >>>> in the paint() >>> >>> Why do we need it? Do we calculate the size in the >>> ToolTipManager.showTipWindow() incorrectly? >>> We call tip.getPreferredSize() there,? does it return different >>> result than in the paint() method? >>> >> No, there it returns the same value as paint() now after GC fix, but >> c.getSize() in paint() returns the JPanel size which is not same as >> preferredSize and it is not enough to contain the text, it seems. > > But the panel and window both are created by our code in > ToolTipManager.showTipWindow, should we adjust it? > But getPreferredSize() uses span calculation+6 which is not present in panel's setSize calculation. I would think using preferredSize is better than meddling with setSize calculation, given that TooltipManager.showTipWindow () also used getPreferredSize() to calculate the tip bounds. From prasanta.sadhukhan at oracle.com Mon Apr 20 18:14:20 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 20 Apr 2020 23:44:20 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <3e37c6d4-4ddb-a829-7504-b2afd92b6996@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> <7ee86f9f-9b63-ec34-6c42-189661dda3fd@oracle.com> <8a676287-9aed-df8b-4638-c6f809e1336f@oracle.com> <8f3179d4-410a-0cc7-61e4-9773b05e6b43@oracle.com> Message-ID: <2e00a232-de21-9724-9eed-bab712696061@oracle.com> On 20-Apr-20 10:20 PM, Prasanta Sadhukhan wrote: > > On 20-Apr-20 10:16 PM, Sergey Bylokhov wrote: >> On 4/20/20 8:34 am, Prasanta Sadhukhan wrote: >>> >>> On 20-Apr-20 8:54 PM, Sergey Bylokhov wrote: >>>> On 4/20/20 2:40 am, Prasanta Sadhukhan wrote: >>>>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.4/ >>>>> >>>>> used the right GC for the tip but we still need the preferredSize >>>>> in the paint() >>>> >>>> Why do we need it? Do we calculate the size in the >>>> ToolTipManager.showTipWindow() incorrectly? >>>> We call tip.getPreferredSize() there,? does it return different >>>> result than in the paint() method? >>>> >>> No, there it returns the same value as paint() now after GC fix, but >>> c.getSize() in paint() returns the JPanel size which is not same as >>> preferredSize and it is not enough to contain the text, it seems. >> >> But the panel and window both are created by our code in >> ToolTipManager.showTipWindow, should we adjust it? >> > But getPreferredSize() uses span calculation+6 which is not present in > panel's setSize calculation. I would think using preferredSize is > better than meddling with setSize calculation, given that > TooltipManager.showTipWindow () also used getPreferredSize() to > calculate the tip bounds. It seems JPanel (component created for LW popup) GC is again null and not in sync with JToolTip's GC so in addition to fix JToolTip's GC, we also need to set GC of JPanel (jn sync with "contents" or tip's GC), so setSize() will be set same as preferredSize. http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.5/ Regards Prasanta From alexey.ivanov at oracle.com Mon Apr 20 19:26:55 2020 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 20 Apr 2020 20:26:55 +0100 Subject: RFR: 8233584: [Win LAF] When navigating the contents of the file list changes in Win LAF In-Reply-To: <9d7be300-667a-5528-f8c5-8b8e2ac0b9cc@oracle.com> References: <60d5b758-df58-9ba7-04a4-1603fa205263@oracle.com> <33cfebf6-2eac-ea58-781b-d8c0283cda4a@oracle.com> <3e20ef5a-6549-0a8e-d017-fc71bff92de6@oracle.com> <9d7be300-667a-5528-f8c5-8b8e2ac0b9cc@oracle.com> Message-ID: <0ae479d0-ef31-a763-afa5-5ce0e21353b9@oracle.com> Hi Bhawesh, Looks good to me. Sorry for my delayed response. I noted that making the test automatic is out of scope at this time, however, it seems to be possible. You don't need to read the list of files. The file list reacts to the even sent by combo box. After the fix, navigating items in the combo box does not send the event until you press Enter. If you add a listener to the combo box, you will be able to check whether the event is sent or not. I also noticed that the updated version opens the pop-up when the combo box is focused and you press Up or Down arrow. Before the fix, the combo box pop-up did not open with the arrow keys: it changed the selection and updated the list of files. Regards, Alexey On 17/04/2020 07:44, Bhawesh Choudhary wrote: > Hi Alexey, > Please review below fix updated as per your suggestion. > > -Bhawesh > > On 4/6/2020 12:22 PM, Bhawesh Choudhary wrote: >> Hi Alexey, >> >> Please find updated Webrev as per suggestion. I couldn't make test >> automatic due to not able to read contents currently being displayed >> in JFileChooser. >> >> JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 >> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.2/ >> >> -Bhawesh >> >> On 4/2/2020 12:17 AM, Alexey Ivanov wrote: >>> Hi Bhawesh, >>> >>> Shall we add >>> @requires |os.family == "windows" >>> to the test? Then it won't be even selected for running by jtreg. >>> >>> It think the copyright year should be updated in both modified >>> files, should it? >>> >>> I'd also suggest using explicit import statements for javax.swing.* >>> classes instead of the wildcard one. >>> >>> Is it possible to make the automatic? However, this is out of scope >>> of this bug. >>> >>> >>> Regards, >>> Alexey >>> | >>> On 31/03/2020 10:16, Bhawesh Choudhary wrote: >>>> Hi, >>>> >>>> Please find updated Webrev as per suggestions [Test case updates >>>> for WindowsLookAndFeel] >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.1/ >>>> >>>> -Bhawesh >>>> >>>> On 3/13/2020 12:10 PM, Bhawesh Choudhary wrote: >>>>> Hi, >>>>> >>>>> Please find updated Webrev as per suggestions [Test name update >>>>> and Code formatting] >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.01/ >>>>> >>>>> -Bhawesh >>>>> >>>>> On 3/4/2020 4:13 PM, Bhawesh Choudhary wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this fix, >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev/ >>>>>> >>>>>> Issue: >>>>>> In Windows LookAndFeel, When navigating Combobox's list of >>>>>> JFileChooser via keys, the contents of JFileChooser changes. >>>>>> >>>>>> Fix: >>>>>> Set flag "JComboBox.isTableCellEditor" to True which prohibits >>>>>> JCombobox from sending selection change event when JCombobox's >>>>>> list selection change happens via keys. >>>>>> >>>>>> >>>>>> Verification: >>>>>> Tested the fix with JFileChooser with WindowsLookAndFeelEnabled >>>>>> as well as BasicLookAndFeel with keys navigation. also added a >>>>>> test case to verify the same. >>>>>> >>>>>> Did not find any misbehavior with the fix. >>>>>> >>>>>> Regards >>>>>> Bhawesh >> > From JAYATHIRTH.D.V at ORACLE.COM Wed Apr 22 06:35:43 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Wed, 22 Apr 2020 12:05:43 +0530 Subject: RFR JDK-8178028: Typing 'C' cannot change the tab layout to WRAP_TAB_LAYOUT In-Reply-To: <3383c21c-36b8-a84d-59d5-09f1cba146c4@oracle.com> References: <3383c21c-36b8-a84d-59d5-09f1cba146c4@oracle.com> Message-ID: Looks good to me if it is verified to pass in our internal CI system also. Thanks, Jay > On 17-Apr-2020, at 8:34 PM, Prasanta Sadhukhan wrote: > > Hi All, > > Please review a test fix for an issue where it is seen that JTabbedPane tabLayoutPolicy was not getting changed from SCROLL_TAB_LAYOUT to WRAP_TAB_LAYOUT. > > This is because the test creates only 5 tabs which fits on the window whereas the JTabbedPane.WRAP_TAB_LAYOUT spec says > > "The tab layout policy for wrapping tabs in multiple runs when all tabs will not fit within a single run" > > so I fixed it by creating multiple tabs which will not fit on screen, so now toggling between SCROLL_TAB_LAYOUT and WRAP_TAB_LAYOUT policy causes the tabs to > > either show only subset of tabs or wrap tabs into multiple lines respectively. > > Also, the subtest of typing "C" to test WRAP_TAB_LAYOUT policy is moved to 1st subtest as currently the test is after "L" which is LEFT tab placement so the tabs will be aligned vertically, > > which will again cause the tabs to fit on window, causing *TAB_LAYOUT policy to not work. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178028 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8178028/webrev.0/ > > Regards > Prasanta From prasanta.sadhukhan at oracle.com Wed Apr 22 06:37:13 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 22 Apr 2020 12:07:13 +0530 Subject: RFR JDK-8178028: Typing 'C' cannot change the tab layout to WRAP_TAB_LAYOUT In-Reply-To: References: <3383c21c-36b8-a84d-59d5-09f1cba146c4@oracle.com> Message-ID: <2e6ff330-9d86-5b68-1923-8de8e172a6b8@oracle.com> internal CI system is automated testing whereas this test is manual . Regards Prasanta On 22-Apr-20 12:05 PM, Jayathirth D v wrote: > Looks good to me if it is verified to pass in our internal CI system also. > > Thanks, > Jay > >> On 17-Apr-2020, at 8:34 PM, Prasanta Sadhukhan wrote: >> >> Hi All, >> >> Please review a test fix for an issue where it is seen that JTabbedPane tabLayoutPolicy was not getting changed from SCROLL_TAB_LAYOUT to WRAP_TAB_LAYOUT. >> >> This is because the test creates only 5 tabs which fits on the window whereas the JTabbedPane.WRAP_TAB_LAYOUT spec says >> >> "The tab layout policy for wrapping tabs in multiple runs when all tabs will not fit within a single run" >> >> so I fixed it by creating multiple tabs which will not fit on screen, so now toggling between SCROLL_TAB_LAYOUT and WRAP_TAB_LAYOUT policy causes the tabs to >> >> either show only subset of tabs or wrap tabs into multiple lines respectively. >> >> Also, the subtest of typing "C" to test WRAP_TAB_LAYOUT policy is moved to 1st subtest as currently the test is after "L" which is LEFT tab placement so the tabs will be aligned vertically, >> >> which will again cause the tabs to fit on window, causing *TAB_LAYOUT policy to not work. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8178028 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8178028/webrev.0/ >> >> Regards >> Prasanta From JAYATHIRTH.D.V at ORACLE.COM Wed Apr 22 06:39:30 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Wed, 22 Apr 2020 12:09:30 +0530 Subject: RFR JDK-8178028: Typing 'C' cannot change the tab layout to WRAP_TAB_LAYOUT In-Reply-To: <2e6ff330-9d86-5b68-1923-8de8e172a6b8@oracle.com> References: <3383c21c-36b8-a84d-59d5-09f1cba146c4@oracle.com> <2e6ff330-9d86-5b68-1923-8de8e172a6b8@oracle.com> Message-ID: <2B8BF241-15DD-4B8F-8F23-0473C3EEE348@ORACLE.COM> Thanks for clarification. +1. Regards, Jay > On 22-Apr-2020, at 12:07 PM, Prasanta Sadhukhan wrote: > > internal CI system is automated testing whereas this test is manual . > > Regards > Prasanta > On 22-Apr-20 12:05 PM, Jayathirth D v wrote: >> Looks good to me if it is verified to pass in our internal CI system also. >> >> Thanks, >> Jay >> >>> On 17-Apr-2020, at 8:34 PM, Prasanta Sadhukhan wrote: >>> >>> Hi All, >>> >>> Please review a test fix for an issue where it is seen that JTabbedPane tabLayoutPolicy was not getting changed from SCROLL_TAB_LAYOUT to WRAP_TAB_LAYOUT. >>> >>> This is because the test creates only 5 tabs which fits on the window whereas the JTabbedPane.WRAP_TAB_LAYOUT spec says >>> >>> "The tab layout policy for wrapping tabs in multiple runs when all tabs will not fit within a single run" >>> >>> so I fixed it by creating multiple tabs which will not fit on screen, so now toggling between SCROLL_TAB_LAYOUT and WRAP_TAB_LAYOUT policy causes the tabs to >>> >>> either show only subset of tabs or wrap tabs into multiple lines respectively. >>> >>> Also, the subtest of typing "C" to test WRAP_TAB_LAYOUT policy is moved to 1st subtest as currently the test is after "L" which is LEFT tab placement so the tabs will be aligned vertically, >>> >>> which will again cause the tabs to fit on window, causing *TAB_LAYOUT policy to not work. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178028 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8178028/webrev.0/ >>> >>> Regards >>> Prasanta From tejpal.rebari at oracle.com Wed Apr 22 06:42:04 2020 From: tejpal.rebari at oracle.com (Tejpal Rebari) Date: Tue, 21 Apr 2020 23:42:04 -0700 (PDT) Subject: RFR: 8229856 [macos] Opening a menu on a JTextField can clear the text selection Message-ID: <0B6CC26F-8F2C-4EBF-8048-2C0B3EF6E8EC@oracle.com> Hi All, Please review the following fix for jdk15. Bug : https://bugs.openjdk.java.net/browse/JDK-8229856 Webrev : http://cr.openjdk.java.net/~trebari/swing/8229856/webrev00/ Issue : This issue exists in AquaLookandFeel only. The issue is that while opening a menu on a JTextFeild using control-click over a selection that has been created by triple clicking clears the existing text selection. AquaCaret.mousePressed disables the behaviour of shouldHandleRelease instance variable of DefaultCaret on a popup trigger event , so the shouldHandleRelease retains its previous value. If the previous value of shouldHandleRelease is true then DefaultCaret.mouseRelease will clear the selection. The third click consume the mouseEvent and sets the shouldHandleRelease to true. To fix this issue we should not call super.MousePressed from AquaCaret on a triple click event. Test : Tested on Mac OS X. Thanks and regards Tejpal -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Apr 22 06:43:39 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 22 Apr 2020 12:13:39 +0530 Subject: RFR: 8233584: [Win LAF] When navigating the contents of the file list changes in Win LAF In-Reply-To: <0ae479d0-ef31-a763-afa5-5ce0e21353b9@oracle.com> References: <60d5b758-df58-9ba7-04a4-1603fa205263@oracle.com> <33cfebf6-2eac-ea58-781b-d8c0283cda4a@oracle.com> <3e20ef5a-6549-0a8e-d017-fc71bff92de6@oracle.com> <9d7be300-667a-5528-f8c5-8b8e2ac0b9cc@oracle.com> <0ae479d0-ef31-a763-afa5-5ce0e21353b9@oracle.com> Message-ID: <6b481b3a-037a-084f-ca8c-33193df0698d@oracle.com> Hi Bhawesh, On 21-Apr-20 12:56 AM, Alexey Ivanov wrote: > Hi Bhawesh, > > Looks good to me. > > Sorry for my delayed response. > > > I noted that making the test automatic is out of scope at this time, > however, it seems to be possible. You don't need to read the list of > files. The file list reacts to the even sent by combo box. After the > fix, navigating items in the combo box does not send the event until > you press Enter. If you add a listener to the combo box, you will be > able to check whether the event is sent or not. > > I also noticed that the updated version opens the pop-up when the > combo box is focused and you press Up or Down arrow. Before the fix, > the combo box pop-up did not open with the arrow keys: it changed the > selection and updated the list of files. > Before pushing this fix, I would like to know if this behaviour change will not be constituted as a regression. Regards Prasanta > > Regards, > Alexey > > On 17/04/2020 07:44, Bhawesh Choudhary wrote: >> Hi Alexey, >> Please review below fix updated as per your suggestion. >> >> -Bhawesh >> >> On 4/6/2020 12:22 PM, Bhawesh Choudhary wrote: >>> Hi Alexey, >>> >>> Please find updated Webrev as per suggestion. I couldn't make test >>> automatic due to not able to read contents currently being displayed >>> in JFileChooser. >>> >>> JBS:???????? https://bugs.openjdk.java.net/browse/JDK-8233584 >>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.2/ >>> >>> -Bhawesh >>> >>> On 4/2/2020 12:17 AM, Alexey Ivanov wrote: >>>> Hi Bhawesh, >>>> >>>> Shall we add >>>> @requires |os.family == "windows" >>>> to the test? Then it won't be even selected for running by jtreg. >>>> >>>> It think the copyright year should be updated in both modified >>>> files, should it? >>>> >>>> I'd also suggest using explicit import statements for javax.swing.* >>>> classes instead of the wildcard one. >>>> >>>> Is it possible to make the automatic? However, this is out of scope >>>> of this bug. >>>> >>>> >>>> Regards, >>>> Alexey >>>> | >>>> On 31/03/2020 10:16, Bhawesh Choudhary wrote: >>>>> Hi, >>>>> >>>>> Please find updated Webrev as per suggestions [Test case updates >>>>> for WindowsLookAndFeel] >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.1/ >>>>> >>>>> -Bhawesh >>>>> >>>>> On 3/13/2020 12:10 PM, Bhawesh Choudhary wrote: >>>>>> Hi, >>>>>> >>>>>> Please find updated Webrev as per suggestions [Test name update >>>>>> and Code formatting] >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.01/ >>>>>> >>>>>> -Bhawesh >>>>>> >>>>>> On 3/4/2020 4:13 PM, Bhawesh Choudhary wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this fix, >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>>>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev/ >>>>>>> >>>>>>> Issue: >>>>>>> In Windows LookAndFeel, When navigating Combobox's list of >>>>>>> JFileChooser via keys, the contents of JFileChooser changes. >>>>>>> >>>>>>> Fix: >>>>>>> Set flag "JComboBox.isTableCellEditor" to True which prohibits >>>>>>> JCombobox from sending selection change event when JCombobox's >>>>>>> list selection change happens via keys. >>>>>>> >>>>>>> >>>>>>> Verification: >>>>>>> Tested the fix with JFileChooser with WindowsLookAndFeelEnabled >>>>>>> as well as BasicLookAndFeel with keys navigation. also added a >>>>>>> test case to verify the same. >>>>>>> >>>>>>> Did not find any misbehavior with the fix. >>>>>>> >>>>>>> Regards >>>>>>> Bhawesh >>> >> > From prasanta.sadhukhan at oracle.com Wed Apr 22 08:10:07 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 22 Apr 2020 13:40:07 +0530 Subject: RFR: 8233584: [Win LAF] When navigating the contents of the file list changes in Win LAF In-Reply-To: <6b481b3a-037a-084f-ca8c-33193df0698d@oracle.com> References: <60d5b758-df58-9ba7-04a4-1603fa205263@oracle.com> <33cfebf6-2eac-ea58-781b-d8c0283cda4a@oracle.com> <3e20ef5a-6549-0a8e-d017-fc71bff92de6@oracle.com> <9d7be300-667a-5528-f8c5-8b8e2ac0b9cc@oracle.com> <0ae479d0-ef31-a763-afa5-5ce0e21353b9@oracle.com> <6b481b3a-037a-084f-ca8c-33193df0698d@oracle.com> Message-ID: <1d9185b8-4eee-dd18-b48f-8503e753b7e0@oracle.com> On 22-Apr-20 12:13 PM, Prasanta Sadhukhan wrote: > Hi Bhawesh, > > On 21-Apr-20 12:56 AM, Alexey Ivanov wrote: >> Hi Bhawesh, >> >> Looks good to me. >> >> Sorry for my delayed response. >> >> >> I noted that making the test automatic is out of scope at this time, >> however, it seems to be possible. You don't need to read the list of >> files. The file list reacts to the even sent by combo box. After the >> fix, navigating items in the combo box does not send the event until >> you press Enter. If you add a listener to the combo box, you will be >> able to check whether the event is sent or not. >> >> I also noticed that the updated version opens the pop-up when the >> combo box is focused and you press Up or Down arrow. Before the fix, >> the combo box pop-up did not open with the arrow keys: it changed the >> selection and updated the list of files. >> > Before pushing this fix, I would like to know if this behaviour change > will not be constituted as a regression. It seems to be in tune with what native windows filechooser does ie opens the popup, so will be pushing this fix. > > Regards > > Prasanta > >> >> Regards, >> Alexey >> >> On 17/04/2020 07:44, Bhawesh Choudhary wrote: >>> Hi Alexey, >>> Please review below fix updated as per your suggestion. >>> >>> -Bhawesh >>> >>> On 4/6/2020 12:22 PM, Bhawesh Choudhary wrote: >>>> Hi Alexey, >>>> >>>> Please find updated Webrev as per suggestion. I couldn't make test >>>> automatic due to not able to read contents currently being >>>> displayed in JFileChooser. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.2/ >>>> >>>> -Bhawesh >>>> >>>> On 4/2/2020 12:17 AM, Alexey Ivanov wrote: >>>>> Hi Bhawesh, >>>>> >>>>> Shall we add >>>>> @requires |os.family == "windows" >>>>> to the test? Then it won't be even selected for running by jtreg. >>>>> >>>>> It think the copyright year should be updated in both modified >>>>> files, should it? >>>>> >>>>> I'd also suggest using explicit import statements for >>>>> javax.swing.* classes instead of the wildcard one. >>>>> >>>>> Is it possible to make the automatic? However, this is out of >>>>> scope of this bug. >>>>> >>>>> >>>>> Regards, >>>>> Alexey >>>>> | >>>>> On 31/03/2020 10:16, Bhawesh Choudhary wrote: >>>>>> Hi, >>>>>> >>>>>> Please find updated Webrev as per suggestions [Test case updates >>>>>> for WindowsLookAndFeel] >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.1/ >>>>>> >>>>>> -Bhawesh >>>>>> >>>>>> On 3/13/2020 12:10 PM, Bhawesh Choudhary wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please find updated Webrev as per suggestions [Test name update >>>>>>> and Code formatting] >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>>>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev.01/ >>>>>>> >>>>>>> -Bhawesh >>>>>>> >>>>>>> On 3/4/2020 4:13 PM, Bhawesh Choudhary wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this fix, >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233584 >>>>>>>> Webrev: http://cr.openjdk.java.net/~psadhukhan/8233584/webrev/ >>>>>>>> >>>>>>>> Issue: >>>>>>>> In Windows LookAndFeel, When navigating Combobox's list of >>>>>>>> JFileChooser via keys, the contents of JFileChooser changes. >>>>>>>> >>>>>>>> Fix: >>>>>>>> Set flag "JComboBox.isTableCellEditor" to True which prohibits >>>>>>>> JCombobox from sending selection change event when JCombobox's >>>>>>>> list selection change happens via keys. >>>>>>>> >>>>>>>> >>>>>>>> Verification: >>>>>>>> Tested the fix with JFileChooser with WindowsLookAndFeelEnabled >>>>>>>> as well as BasicLookAndFeel with keys navigation. also added a >>>>>>>> test case to verify the same. >>>>>>>> >>>>>>>> Did not find any misbehavior with the fix. >>>>>>>> >>>>>>>> Regards >>>>>>>> Bhawesh >>>> >>> >> From prasanta.sadhukhan at oracle.com Wed Apr 22 08:29:49 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 22 Apr 2020 13:59:49 +0530 Subject: RFR: 8229856 [macos] Opening a menu on a JTextField can clear the text selection In-Reply-To: <0B6CC26F-8F2C-4EBF-8048-2C0B3EF6E8EC@oracle.com> References: <0B6CC26F-8F2C-4EBF-8048-2C0B3EF6E8EC@oracle.com> Message-ID: <86c17738-5413-8b9f-eb2d-1d311d71a960@oracle.com> Hi Tejpal, Does it need to be triple click of any button or only left mouse button? If only left, then it needs to be checked? Also, I guess the test can be automated by calling robot to do 3 clicks and then calling JTextField.getSelectedText() to see if the text is still selected or not. Regards Prasanta On 22-Apr-20 12:12 PM, Tejpal Rebari wrote: > > Hi All, > > Please review the following fix for jdk15. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8229856 > > Webrev : http://cr.openjdk.java.net/~trebari/swing/8229856/webrev00/ > > Issue : This issue exists in AquaLookandFeel only. > > The issue is that while opening a menu on a JTextFeild using > control-click over a selection > > ?that has been created by triple clicking ?clears the existing text > selection. > > AquaCaret.mousePressed disables the behaviour of > shouldHandleRelease?instance variable of DefaultCaret > > on a popup trigger?event , so the shouldHandleRelease retains its > previous value. > > If the previous value of shouldHandleRelease is true then > DefaultCaret.mouseRelease will clear the selection. > > The third click consume the mouseEvent and sets the > shouldHandleRelease to true. > > To fix this issue we should not call super.MousePressed?from > AquaCaret?on a triple click event. > > Test : Tested on Mac OS X. > > Thanks and regards > > Tejpal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Apr 22 09:35:38 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 22 Apr 2020 15:05:38 +0530 Subject: RFR JDK-8242410: JEditorPane with test/html type and zero margins is not shown In-Reply-To: <789b853e-b2df-82fb-96c9-b5836728c4b0@oracle.com> References: <270d702e-87b1-4f68-a273-d5446af7d520@oracle.com> <789b853e-b2df-82fb-96c9-b5836728c4b0@oracle.com> Message-ID: The regression caused by change in this method was because the rootView layout was changed in those fix(es), but this code is only changing the preferredSize height but I can understand the scepticism. I think since this fix is more about margin, it should be placed in more appropriate class related to borders/margin so I have placed my fix in BasicBorders and not in BasicTextUI. http://cr.openjdk.java.net/~psadhukhan/8242410/webrev.1/ Regards Prasanta On 16-Apr-20 4:58 PM, Sergey Bylokhov wrote: > Hi, Prasanta. > > Remembering the number of regressions caused by the changes in this > method, I suggest to improve it by some additional code only when we > investigate the root cause of all previous issues. The general > approach of using zeros as non-initialized flags seems broken. > > On 4/13/20 3:06 am, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that when >> JEditorPane is created with empty text and zero top and bottom >> insets, the text is not shown after updating it by the method >> setText(String) >> >> This is because the the JEditorPane height is not updated and remains >> 0 if the margin top/botton insets are 0. >> >> Proposed fix is to check if the margin being set is less than default >> margin, then update the margin to the default. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8242410 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8242410/webrev.0/ >> >> I also considered changing getPreferredSize() to update the rootView >> size if height is 0, but it seems it has caused some regression in >> the past, so abstained from that >> >> /-else if (d.width == 0 && d.height == 0) {/ >> /+//else if (d.width == 0 || d.height == 0) {/ >> >> /??????????????? // Probably haven't been layed out yet, force some >> sort of// >> //??????????????? // initial sizing.// >> //??????????????? rootView.setSize(Integer.MAX_VALUE, >> Integer.MAX_VALUE);// >> //??????????? }/ >> >> Regards >> Prasanta > > From JAYATHIRTH.D.V at ORACLE.COM Thu Apr 23 17:02:50 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Thu, 23 Apr 2020 22:32:50 +0530 Subject: RFR JDK-8226464:TitledBorder label appears cut off on hidpi devices In-Reply-To: <3550ed7c-881b-1686-2047-e8763fe9dae1@oracle.com> References: <30e3e728-413c-620a-72bd-a891133832d9@oracle.com> <3aa5eaa9-3720-1513-d8b8-08722d3d6af7@oracle.com> <805e20b1-3f56-aaa7-4f9d-7809a7d2bfea@oracle.com> <3550ed7c-881b-1686-2047-e8763fe9dae1@oracle.com> Message-ID: +1. Thanks, Jay > On 16-Apr-2020, at 4:44 PM, Sergey Bylokhov wrote: > > Looks fine. > > On 4/15/20 8:32 pm, Prasanta Sadhukhan wrote: >> Yes, 8075918 fix also works ok with this fix as I can see. >> Regards >> Prasanta >> On 15-Apr-20 10:37 PM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> >>> That additional clipping was added as part of JDK-8075918, can you please confirm that JDK-8075918 fix will not be broken by the current one. >>> >>> On 4/15/20 5:52 am, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue where it is seen that the TitledBorderLabel is cutoff for uiScale>1.25 for SynthLookAndFeel. >>>> >>>> It is found that in BasicLabelUI, used for other L&Fs,where the issue is not seen, the paint() method calls layout()=>SwingUtilities.layoutCompoundLabel() to get the clipped version of the label string >>>> >>>> but SynthLabelUI#paint calls SynthGraphicsUtils#paintText which calls layoutText() which also used SwingUtilities.layoutCompoundLabel() to get the clipped version of the label string but still it additionally does its own clipping using text bounds. >>>> >>>> This bounds is passed in both Basic L&F and Synth L&F via paintEnabledText() and paintText() respectively to SwingUtilities2.drawStringUnderlineCharAt() to drawthe string, so only additional clipping done in SynthL&F is the cause of the problem. >>>> >>>> Proposed fix is to remove this additional clipping in SynthL&F. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8226464 >>>> >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8226464/webrev.0/ >>>> >>>> Regards >>>> Prasanta >>> >>> > > > -- > Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Apr 24 12:44:49 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 24 Apr 2020 18:14:49 +0530 Subject: RFR JDK-8172269: When checking the default behaviour for a scroll tab layout and checking the 'opaque' checkbox, the area behind tabs is not red Message-ID: Hi All, Please review a fix for an issue where it is seen that the JTabbedPane background for SCROLL_TAB_LAYOUT policy is not same as what is set by user. This is in continuation with the fix done inJDK-8007563 and JDK-8078269 where the fix was done for WRAP_TAB_LAYOUT policy. There, the fix checks if the "TabbedPane.tabAreaBackground" property set by OceanTheme or other L&Fs would be used only if the background color is "UIResource" otherwise the backgroundcolor which was set by the user should be used. The same check is now applied to SCROLL_TAB_LAYOUT policy too to have consistent behaviour. Bug: https://bugs.openjdk.java.net/browse/JDK-8172269 webrev: http://cr.openjdk.java.net/~psadhukhan/8172269/webrev.0/ Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Apr 24 22:55:36 2020 From: philip.race at oracle.com (Philip Race) Date: Fri, 24 Apr 2020 15:55:36 -0700 Subject: RFR JDK-8232243:Wrong caret position in JTextPane on Windows with a screen resolution > 100% In-Reply-To: <8bc45f92-3f5e-ba36-8b24-47e0d46dba02@oracle.com> References: <8bc45f92-3f5e-ba36-8b24-47e0d46dba02@oracle.com> Message-ID: <5EA36E68.9080403@oracle.com> In the test 56 textPane.setFont(new java.awt.Font("Arial", Font.PLAIN, 12)); you should use a font you know exists. If the idea is that this test is just for windows, then @requires windows ? And 94 System.setProperty( "sun.java2d.uiScale", "1.5" ); should be set as a command line property to the test since that is what we do elsewhere, then you can have the test run several times at different scales. Also currently 1.5 is truncated to 1 except on Windows ... If you want to test on Linux or Mac you need 2. Another reason to use the command line way of doing it. -phil On 4/16/20, 3:16 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that, with a screen > resolution higher than 100% and then clicking in a JTextPane, the > caret (insertion point) is not aligned with the cursor. > > The issue seems to stem from the fact that caret position calculation > in DefaultCaret class utilises API that uses integer calculation than > floating point calculations. > > This issue is in continuation to the fix done for JDK-8199441 where > the issue was fixed for JTextArea. > [http://hg.openjdk.java.net/jdk/jdk/rev/480c2ae4d031] > > The code flow for JTextArea was > DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset > > > whereas for JTextPane it it is > DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>GlyphPainter1#viewToModel=>Utilities.getTabbedOffset > > Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses > integer arithmetic to get the caret position. > The same getTabbedOffset uses Font.getStringBounds() which uses > floating point arithmetic via Rectangle2D.Float. > > Proposed fix is to make sure proper floating point getTabbedOffset API > is used so that floating point calculations is done for char width. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8232243 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.0/ > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Sat Apr 25 04:31:19 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 25 Apr 2020 10:01:19 +0530 Subject: RFR JDK-8232243:Wrong caret position in JTextPane on Windows with a screen resolution > 100% In-Reply-To: <5EA36E68.9080403@oracle.com> References: <8bc45f92-3f5e-ba36-8b24-47e0d46dba02@oracle.com> <5EA36E68.9080403@oracle.com> Message-ID: Thanks for your review. All comments incorporated http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.1/ Regards Prasaant On 25-Apr-20 4:25 AM, Philip Race wrote: > In the test > 56 textPane.setFont(new java.awt.Font("Arial", Font.PLAIN, 12)); > > you should use a font you know exists. If the idea is that this test is just > for windows, then @requires windows ? > > And > 94 System.setProperty( "sun.java2d.uiScale", "1.5" ); > > should be set as a command line property to the test since that is what we do > elsewhere, then you can have the test run several times at different scales. > > Also currently 1.5 is truncated to 1 except on Windows ... > > If you want to test on Linux or Mac you need 2. > Another reason to use the command line way of doing it. > > > -phil > > > On 4/16/20, 3:16 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for an issue where it is seen that, with a screen >> resolution higher than 100% and then clicking in a JTextPane, the >> caret (insertion point) is not aligned with the cursor. >> >> The issue seems to stem from the fact that caret position calculation >> in DefaultCaret class utilises API that uses integer calculation than >> floating point calculations. >> >> This issue is in continuation to the fix done for JDK-8199441 where >> the issue was fixed for JTextArea. >> [http://hg.openjdk.java.net/jdk/jdk/rev/480c2ae4d031] >> >> The code flow for JTextArea was >> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset >> >> >> whereas for JTextPane it it is >> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>GlyphPainter1#viewToModel=>Utilities.getTabbedOffset >> >> Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses >> integer arithmetic to get the caret position. >> The same getTabbedOffset uses Font.getStringBounds() which uses >> floating point arithmetic via Rectangle2D.Float. >> >> Proposed fix is to make sure proper floating point getTabbedOffset >> API is used so that floating point calculations is done for char width. >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8232243 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.0/ >> >> Regards >> Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sat Apr 25 14:31:47 2020 From: philip.race at oracle.com (Philip Race) Date: Sat, 25 Apr 2020 07:31:47 -0700 Subject: RFR JDK-8232243:Wrong caret position in JTextPane on Windows with a screen resolution > 100% In-Reply-To: References: <8bc45f92-3f5e-ba36-8b24-47e0d46dba02@oracle.com> <5EA36E68.9080403@oracle.com> Message-ID: <5EA449D3.1010307@oracle.com> 96 SwingUtilities.invokeAndWait(() -> createUI()); 97 98 Point p = textPane.getLocationOnScreen(); 99 Robot robot = new Robot(); For the sake of stability would it be better to create the robot and wait for idle before getting the pane location ? -phil. On 4/24/20, 9:31 PM, Prasanta Sadhukhan wrote: > > Thanks for your review. All comments incorporated > > http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.1/ > > Regards > Prasaant > On 25-Apr-20 4:25 AM, Philip Race wrote: >> In the test >> 56 textPane.setFont(new java.awt.Font("Arial", Font.PLAIN, 12)); >> >> you should use a font you know exists. If the idea is that this test is just >> for windows, then @requires windows ? >> >> And >> 94 System.setProperty( "sun.java2d.uiScale", "1.5" ); >> >> should be set as a command line property to the test since that is what we do >> elsewhere, then you can have the test run several times at different scales. >> >> Also currently 1.5 is truncated to 1 except on Windows ... >> >> If you want to test on Linux or Mac you need 2. >> Another reason to use the command line way of doing it. >> >> >> -phil >> >> >> On 4/16/20, 3:16 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for an issue where it is seen that, with a >>> screen resolution higher than 100% and then clicking in a JTextPane, >>> the caret (insertion point) is not aligned with the cursor. >>> >>> The issue seems to stem from the fact that caret position >>> calculation in DefaultCaret class utilises API that uses integer >>> calculation than floating point calculations. >>> >>> This issue is in continuation to the fix done for JDK-8199441 where >>> the issue was fixed for JTextArea. >>> [http://hg.openjdk.java.net/jdk/jdk/rev/480c2ae4d031] >>> >>> The code flow for JTextArea was >>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset >>> >>> >>> whereas for JTextPane it it is >>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>GlyphPainter1#viewToModel=>Utilities.getTabbedOffset >>> >>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses >>> integer arithmetic to get the caret position. >>> The same getTabbedOffset uses Font.getStringBounds() which uses >>> floating point arithmetic via Rectangle2D.Float. >>> >>> Proposed fix is to make sure proper floating point getTabbedOffset >>> API is used so that floating point calculations is done for char width. >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8232243 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.0/ >>> >>> Regards >>> Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Apr 27 04:13:51 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 27 Apr 2020 09:43:51 +0530 Subject: RFR JDK-8232243:Wrong caret position in JTextPane on Windows with a screen resolution > 100% In-Reply-To: <5EA449D3.1010307@oracle.com> References: <8bc45f92-3f5e-ba36-8b24-47e0d46dba02@oracle.com> <5EA36E68.9080403@oracle.com> <5EA449D3.1010307@oracle.com> Message-ID: Sure..test updated... http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.2/ Regards Prasanta On 25-Apr-20 8:01 PM, Philip Race wrote: > > ? 96???????????? SwingUtilities.invokeAndWait(() -> createUI()); > ? 97 > ? 98???????????? Point p = textPane.getLocationOnScreen(); > 99 Robot robot = new Robot(); > > For the sake of stability would it be better to create the robot and wait > for idle before getting the pane location ? > > -phil. > > On 4/24/20, 9:31 PM, Prasanta Sadhukhan wrote: >> >> Thanks for your review. All comments incorporated >> >> http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.1/ >> >> Regards >> Prasaant >> On 25-Apr-20 4:25 AM, Philip Race wrote: >>> In the test >>> 56 textPane.setFont(new java.awt.Font("Arial", Font.PLAIN, 12)); >>> >>> you should use a font you know exists. If the idea is that this test is just >>> for windows, then @requires windows ? >>> >>> And >>> 94 System.setProperty( "sun.java2d.uiScale", "1.5" ); >>> >>> should be set as a command line property to the test since that is what we do >>> elsewhere, then you can have the test run several times at different scales. >>> >>> Also currently 1.5 is truncated to 1 except on Windows ... >>> >>> If you want to test on Linux or Mac you need 2. >>> Another reason to use the command line way of doing it. >>> >>> >>> -phil >>> >>> >>> On 4/16/20, 3:16 AM, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for an issue where it is seen that, with a >>>> screen resolution higher than 100% and then clicking in a >>>> JTextPane, the caret (insertion point) is not aligned with the cursor. >>>> >>>> The issue seems to stem from the fact that caret position >>>> calculation in DefaultCaret class utilises API that uses integer >>>> calculation than floating point calculations. >>>> >>>> This issue is in continuation to the fix done for JDK-8199441 where >>>> the issue was fixed for JTextArea. >>>> [http://hg.openjdk.java.net/jdk/jdk/rev/480c2ae4d031] >>>> >>>> The code flow for JTextArea was >>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset >>>> >>>> >>>> whereas for JTextPane it it is >>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>GlyphPainter1#viewToModel=>Utilities.getTabbedOffset >>>> >>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses >>>> integer arithmetic to get the caret position. >>>> The same getTabbedOffset uses Font.getStringBounds() which uses >>>> floating point arithmetic via Rectangle2D.Float. >>>> >>>> Proposed fix is to make sure proper floating point getTabbedOffset >>>> API is used so that floating point calculations is done for char >>>> width. >>>> >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8232243 >>>> >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.0/ >>>> >>>> Regards >>>> Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Apr 27 04:51:58 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 26 Apr 2020 21:51:58 -0700 Subject: RFR JDK-8172269: When checking the default behaviour for a scroll tab layout and checking the 'opaque' checkbox, the area behind tabs is not red In-Reply-To: References: Message-ID: Looks fine. On 4/24/20 5:44 am, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for an issue where it is seen that the JTabbedPane background for SCROLL_TAB_LAYOUT policy is not same as what is set by user. > > This is in continuation with the fix done inJDK-8007563 and JDK-8078269 > where the fix was done for WRAP_TAB_LAYOUT policy. > > There, the fix checks if the "TabbedPane.tabAreaBackground" property set by OceanTheme or other L&Fs would be used only if the background color is "UIResource" otherwise the backgroundcolor which was set by the user should be used. The same check is now applied to SCROLL_TAB_LAYOUT policy too to have consistent behaviour. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172269 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8172269/webrev.0/ > > Regards > > Prasanta > > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Mon Apr 27 16:02:44 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 27 Apr 2020 21:32:44 +0530 Subject: RFR JDK-8067986: Test javax/swing/JComboBox/ConsumedKeyTest/ConsumedKeyTest.java fails Message-ID: <94eb7ac7-d392-6345-23ed-43868d4e3203@oracle.com> Hi All, Please review a fix for an issue where it is seen that ComboBox is consuming Enter key without taking action on it. The test was introduced by JDK-8058193 where the "Escape" and "Enter" key problem for ComboBox was fixed for mac, but it was seen still for windows and linux. This is because for windows & linux, BasicComboBoxUI#accept "Enter" key but when actual actionPerformed() was done for Enter Key, it was seen that InputMap for VK_ENTER is not set up so no action is performed on it. Proposed fix is to check upfront whether to accept this key VK_ENTER by checking if InputMap for VK_ENTER is set up or not, else fall back to SwingUtilities#notifyAction() where the user actionPerformed will be called instead. Bug: https://bugs.openjdk.java.net/browse/JDK-8067986 webrev: http://cr.openjdk.java.net/~psadhukhan/8067986/webrev.0/ Regards Prasanta From pankaj.b.bansal at oracle.com Tue Apr 28 10:56:14 2020 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Tue, 28 Apr 2020 16:26:14 +0530 Subject: [15] RFR JDK-8220811: SpinnerNumberModel floating point rounding issue In-Reply-To: References: <4cfd1bd2-0a45-4b23-97a3-e1a773db1785@default> <75808EB0-5C20-4698-92F1-D14A3619E676@sap.com> <27f5dd3f-0d31-0690-1ea2-8277e8f969cf@oracle.com> <65102afd-0078-12cd-7a17-24a9b27548aa@oracle.com> <785ec7c7-efa5-56f0-b695-734f174be49c@oracle.com> <3a4a2cb9-4735-405b-ba6d-6e30131f70b5@default> <30730877-5548-46fb-8b8c-716f3b239ba0@default> <0D81D11D-910C-4B0F-AF02-E3D768F21D6C@sap.com> <67d61ba9-0f42-31d6-e03d-2e715df67c77@oracle.com> Message-ID: <8fc5a266-a155-dae8-13fc-78c36778eb99@oracle.com> Hello Sergey, < On 4/7/20 9:18 am, Pankaj Bansal wrote: >> << Probably I missed the point but isn't it too many changes for this? >> <> currentStep, positeveCount, negativeCount; >> <> all changes are needed, I'll check closely. >> Most of these changes are needed to support changing the value from >> text field directly instead of up/down button. Changing from >> textfield can change min/max allowed etc. > > Ok, can we split the change related to setting the data via text field > from the change of iteration over the number of steps using count? > I think it could be fixed separately. > >> >> Regards, >> Pankaj >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Tuesday, April 7, 2020 9:46 PM >> To: Pankaj Bansal ; Volodin, Vladislav >> >> Cc: swing-dev at openjdk.java.net; Jason Mehrens >> ; Alexey Ivanov >> Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel >> floating point rounding issue >> >> Probably I missed the point but isn't it too many changes for this? >> >> Number base, expectedNewValue, newMinimum, newMaximum; int >> currentStep, positeveCount, negativeCount; >> >> I expected that we will have only one new "count" field, probably all >> changes are needed, I'll check closely. >> >> On 4/7/20 9:01 am, Pankaj Bansal wrote: >>> I tried few things? and I think this version is working fine. I >>> tested this version with few tests and this seem to work in all >>> cases. Please have a look. >> >> The test from the first version of the fix missed? >> >>> >>> webrev: http://cr.openjdk.java.net/~pbansal/8220811/webrev02/ >>> >>> Regards, >>> Pankaj >>> >>> -----Original Message----- >>> From: Volodin, Vladislav >>> Sent: Sunday, March 15, 2020 2:03 AM >>> To: Pankaj Bansal >>> Cc: swing-dev at openjdk.java.net; Jason Mehrens >>> ; Sergey Bylokhov >>> ; Alexey Ivanov >>> Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel >>> floating point rounding issue >>> >>> Hello Pankaj, >>> >>> I am not the reviewer, but I agree with Jason. To me >>> p1.equals(Double.NaN) looks confusing. Because people might think >>> that it will be equivalent to p1 == Double.NaN, that will return >>> false, when p1 is also NaN >>> (https://urldefense.com/v3/__https://stackoverflow.com/questions/8819738/why-does-double-nan-double-nan-return-false__;!!GqivPVa7Brio!MCTIuSS1NcMZWK7ZWOAVUhgC-AoVMYwCGbgTiDOH5pO2PQfW7b7XN-hLRtqBuhi6XnVl$ >>> ). >>> I prefer to use the dedicated method such as "public static boolean >>> isNaN(double v)". It looks self-descriptive. >>> >>> Meanwhile, I remember you sentence regarding the number of steps: >>> ????? > double min=-.15,max=0.15,stepsize=.05, the steps is >>> calculated as 5. double min=-.15,max=0.20,stepsize=.05, the steps is >>> calculated as 7 instead of 6. >>> I checked this part with the code: >>> >>> ????????? Double min = -.15; >>> ????????? Double max = 0.15; >>> ????????? Double stepsize = .05; >>> ????????? Double steps = (max - min) / stepsize; >>> >>> And I found out that in this case the number of steps will be >>> 5,999999....., but we can compensate it with either Math.round, it >>> will return 6, or we can add the "epsilon" value to "max", and count >>> the number of steps as it is: >>> ????????? Double max = 0.15 + Math.ulp(1.0); Steps count will be >>> 6.00000238418579. >>> >>> Since there is no value in Double (and probably float) less than >>> Math.ulp (or epsilon, if we use this term), it will be probably safe >>> to use my approach. What do you think? >>> >>> Kind regards, >>> Vlad >>> >>> ?On 14.03.20, 15:51, "Pankaj Bansal" >>> wrote: >>> >>> ????? Hello Jason, >>> ????? ????? << I would assume newMinimum.equals(Double.NaN) and >>> newMinimum.equals(Float.NaN) should always evaluate to false. >>> ????? It seems to work as expected. >>> ????? Double p1 = Double.NaN; >>> ????? Double p2 = 1.0; >>> ????? System.out.println(p1.equals(Double.NaN)); //prints true >>> ????? System.out.println(p2.equals(Double.NaN)); //prints false >>> ????? ????? Regards, >>> ????? Pankaj >>> ????? ????? -----Original Message----- >>> ????? From: Jason Mehrens >>> ????? Sent: Saturday, March 14, 2020 8:09 PM >>> ????? To: Pankaj Bansal ; Sergey >>> Bylokhov ; Alexey Ivanov >>> ; Volodin, Vladislav >>> >>> ????? Cc: swing-dev at openjdk.java.net >>> ????? Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel >>> floating point rounding issue >>> ????? ????? Pankaj, >>> ????? ????? I would assume newMinimum.equals(Double.NaN) and >>> newMinimum.equals(Float.NaN) should always evaluate to false. >>> Perhaps you want to use Float.isNaN and Double.isNaN instead? >>> ????? ????? Jason >>> ????? ????? ________________________________________ >>> ????? From: swing-dev on behalf >>> of Pankaj Bansal >>> ????? Sent: Saturday, March 14, 2020 8:11 AM >>> ????? To: Sergey Bylokhov; Alexey Ivanov; Volodin, Vladislav >>> ????? Cc: swing-dev at openjdk.java.net >>> ????? Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel >>> floating point rounding issue >>> ????? ????? Hello Sergey, >>> ????? ????? << It will differ for two cases: >>> ??????? - The error will not be accumulated when the counter will >>> move forward/backward, currently the result might different on each >>> iteration. >>> ??????? - Initial/Default value will never be skipped due to counter=0 >>> ????? ????? I tried to code according to my understanding of the >>> idea. I have created a preliminary webrev to demonstrate what I am >>> doing. This is nowhere final, so please ignore the optimizations. >>> Please have a look. >>> ????? As I was thinking, the precision error is creating issue while >>> creating the step count. I have to do lot of stuff to allow values >>> to be changed by editing the textfield. There are some other issues >>> also, like the double value is formatted according to the formatter >>> and that is also causing problems. >>> ????? ????? webrev: >>> http://cr.openjdk.java.net/~pbansal/8220811/webrev01/ >>> ????? ????? Regards, >>> ????? Pankaj >>> ????? ????? ????? -----Original Message----- >>> ????? From: Sergey Bylokhov >>> ????? Sent: Wednesday, March 11, 2020 5:33 AM >>> ????? To: Pankaj Bansal ; Alexey Ivanov >>> ; Volodin, Vladislav >>> >>> ????? Cc: swing-dev at openjdk.java.net >>> ????? Subject: Re: [15] RFR JDK-8220811: SpinnerNumberModel >>> floating point rounding issue >>> ????? ????? On 3/10/20 5:34 am, Pankaj Bansal wrote: >>> ????? > Hello Sergey/Vlad/Alexey, >>> ????? > >>> ????? > Sorry, I could not reply to this earlier. I have one doubt >>> about this approach. Won't the calculation of stepCount itself >>> suffer from floating point issue? I mean the user will pass min, >>> max, stepsize, then wont the calculation of steps required to go >>> from min to max will also suffer from same floating point issue? I >>> think there can be an rounding of error of -1 or +1 in calculation >>> of step count. >>> ????? ????? It will differ for two cases: >>> ??????? - The error will not be accumulated when the counter will >>> move forward/backward, currently the result might different on each >>> iteration. >>> ??????? - Initial/Default value will never be skipped due to counter=0 >>> ????? ????? > >>> ????? > eg. >>> ????? > >>> ????? > int steps =0; >>> ????? > >>> ????? > for (double i=min+stepsize; i<=max; i+=stepsize) >>> ????? >?????? steps++; >>> ????? > >>> ????? > double min=-.15,max=0.15,stepsize=.05, the steps is >>> calculated as 5. double min=-.15,max=0.20,stepsize=.05, the steps is >>> calculated as 7 instead of 6. >>> ????? > >>> ????? > >>> ????? > The reason is that, there is floating point error in first >>> case, but it is not present in second case. >>> ????? > >>> ????? > I think the best we can do here is as Sergey suggested in >>> his first >>> ????? > reply to use Math.fma to reduce the floating point error >>> chances from >>> ????? > 2 to 1 or just close this as not an issue >>> ????? > >>> ????? > Regards, >>> ????? > >>> ????? > Pankaj >>> ????? > >>> ????? > >>> ????? > On 19/02/20 3:49 AM, Sergey Bylokhov wrote: >>> ????? >> I think it should work, the step will counts from the >>> default value. >>> ????? >> >>> ????? >> So currently: >>> ????? >> 1. if the user set default value to X1 and then he iterates >>> forward 100 times then he will get some X2. During this calculation, >>> he could get "100" rounding issues. >>> ????? >> 2. If later the user decides iterates backward then most >>> probably he will not get X1, and the amount of possible "rounding >>> issues" will be 200. >>> ????? >> >>> ????? >> If the user will repeat steps 1. and 2. then each time the >>> values will "float". >>> ????? >> >>> ????? >> If we will use counter then in the worst case we will get >>> only two roundings per step: X1+step*100 = X2(if we will use fma we >>> will get only one for every step). >>> ????? >> >>> ????? >> It will not solve all issues but at least will make the >>> iteration "stable". >>> ????? >> >>> ????? >> On 2/17/20 1:59 am, Alexey Ivanov wrote: >>> ????? >>> Hi Vlad, >>> ????? >>> >>> ????? >>> The idea looks reasonable. However, it does not allow for >>> manual editing. The cases where max and min values are not multiples >>> of step would be hard to handle with this approach. For example: max >>> = 10.05, min = 0.01, step = 0.1; how many ticks are there? What if >>> the user enters 1.01015; the value should change to 1.11015 or 0.91015. >>> ????? >>> >>> ????? >>> On 13/02/2020 22:22, Volodin, Vladislav wrote: >>> ????? >>>> Hello Sergey, Alexey and Pankaj, >>> ????? >>>> >>> ????? >>>> I am reading the current discussion and I was thinking >>> about an idea changing the code in the way that instead of working >>> with float/double numbers we work with integer ticks. For example, >>> the model remembers the min/max/step values and calculates a number >>> of steps required to reach from min to max. All increment/decrement >>> actions are done against the current ?tick? value. If the current >>> ?tick? reaches 0 - we return min; if maxTick ? we return max. And >>> the current value can be always counted as (min + tick * step) if >>> tick is neither zero, nor max tick count. >>> ????? >>>> >>> ????? >>>> At least if we deal with integer ticks, but all reading >>> operations calculate on the fly, we will be able to control the >>> representativeness of output. >>> ????? >>>> >>> ????? >>>> As always, I don?t know all the details and possible >>> consequences, so feel free to ignore my email, if I am wrong. >>> ????? >>>> >>> ????? >>>> Kind regards, >>> ????? >>>> Vlad >>> ????? >>>> >>> ????? >>>> Sent from myPad >>> ????? >>>> >>> ????? >>>>> On 13. Feb 2020, at 22:34, Sergey Bylokhov >>> wrote: >>> ????? >>>>> >>> ????? >>>>> On 2/12/20 8:21 am, Alexey Ivanov wrote: >>> ????? >>>>>> The bug report says that going from -0.15 to -0.10 does >>> not allow going back to -0.15. This happens because the result of >>> this sequence of operations cannot be represented exactly, or, in >>> other words, because of rounding errors; or rather the result is >>> less than the set minimal value. >>> ????? >>>>>> Can we set the value of the spinner to the set minimal >>> value instead of disallowing the operation. I mean, after going up >>> the displayed value is -0.10; going down by 0.05 gives the result >>> which is less than the minimal value for the spinner, and thus going >>> down is not allowed. What if we set the value of the spinner to its >>> minimal value instead? >>> ????? >>>>> In this case, we will need to update all types including >>> int. >>> ????? >>>>> Isn't it will be surprised that the spinner will show >>> the value which is not calculated as "defaultValue + stepValue * >>> stepCount"? >>> ????? >>>>> >>> ????? >>>>> >>> ????? >>>>> -- >>> ????? >>>>> Best regards, Sergey. >>> ????? >> >>> ????? >> >>> ????? > >>> ????? ????? ????? -- >>> ????? Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. >> > > From prasanta.sadhukhan at oracle.com Tue Apr 28 13:07:23 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 28 Apr 2020 18:37:23 +0530 Subject: RFR JDK-8169953:JComboBox/8057893: ComboBoxEdited event is not fired! on Windows Message-ID: Hi All, This test was added to ProblemList due to it failing on windows and sometimes on mac. But? I have tried with latest build on local windows and mac system and also on mach5 system (job detail in JBS) where it passed for several iterations so we can remove it from ProblemList Bug: https://bugs.openjdk.java.net/browse/JDK-8169953 diff -r 79463a078a39 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt? Mon Apr 27 10:37:30 2020 +0530 +++ b/test/jdk/ProblemList.txt? Tue Apr 28 18:35:27 2020 +0530 @@ -780,7 +780,6 @@ ?javax/swing/Action/8133039/bug8133039.java 8196089 windows-all,macosx-all ?javax/swing/JComboBox/6559152/bug6559152.java 8196090 windows-all,macosx-all ?javax/swing/JComboBox/8032878/bug8032878.java 8196092,8196439 windows-all,macosx-all,linux-all *-javax/swing/JComboBox/8057893/bug8057893.java 8169953 windows-all,macosx-all* ?javax/swing/JComboBox/8072767/bug8072767.java 8196093 windows-all,macosx-all ?javax/swing/JComponent/4337267/bug4337267.java 8146451 windows-all ?javax/swing/JFileChooser/4524490/bug4524490.java 8042380 generic-all Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Apr 28 23:09:09 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 28 Apr 2020 16:09:09 -0700 (PDT) Subject: RFR JDK-8232243:Wrong caret position in JTextPane on Windows with a screen resolution > 100% In-Reply-To: References: <8bc45f92-3f5e-ba36-8b24-47e0d46dba02@oracle.com> <5EA36E68.9080403@oracle.com> <5EA449D3.1010307@oracle.com> Message-ID: <5EA8B795.3060405@oracle.com> +1 from me. -phil. On 4/26/20, 9:13 PM, Prasanta Sadhukhan wrote: > > Sure..test updated... > > http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.2/ > > Regards > Prasanta > On 25-Apr-20 8:01 PM, Philip Race wrote: >> >> 96 SwingUtilities.invokeAndWait(() -> createUI()); >> 97 >> 98 Point p = textPane.getLocationOnScreen(); >> 99 Robot robot = new Robot(); >> >> For the sake of stability would it be better to create the robot and wait >> for idle before getting the pane location ? >> >> -phil. >> >> On 4/24/20, 9:31 PM, Prasanta Sadhukhan wrote: >>> >>> Thanks for your review. All comments incorporated >>> >>> http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.1/ >>> >>> Regards >>> Prasaant >>> On 25-Apr-20 4:25 AM, Philip Race wrote: >>>> In the test >>>> 56 textPane.setFont(new java.awt.Font("Arial", Font.PLAIN, 12)); >>>> >>>> you should use a font you know exists. If the idea is that this test is just >>>> for windows, then @requires windows ? >>>> >>>> And >>>> 94 System.setProperty( "sun.java2d.uiScale", "1.5" ); >>>> >>>> should be set as a command line property to the test since that is what we do >>>> elsewhere, then you can have the test run several times at different scales. >>>> >>>> Also currently 1.5 is truncated to 1 except on Windows ... >>>> >>>> If you want to test on Linux or Mac you need 2. >>>> Another reason to use the command line way of doing it. >>>> >>>> >>>> -phil >>>> >>>> >>>> On 4/16/20, 3:16 AM, Prasanta Sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for an issue where it is seen that, with a >>>>> screen resolution higher than 100% and then clicking in a >>>>> JTextPane, the caret (insertion point) is not aligned with the >>>>> cursor. >>>>> >>>>> The issue seems to stem from the fact that caret position >>>>> calculation in DefaultCaret class utilises API that uses integer >>>>> calculation than floating point calculations. >>>>> >>>>> This issue is in continuation to the fix done for JDK-8199441 >>>>> where the issue was fixed for JTextArea. >>>>> [http://hg.openjdk.java.net/jdk/jdk/rev/480c2ae4d031] >>>>> >>>>> The code flow for JTextArea was >>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset >>>>> >>>>> >>>>> whereas for JTextPane it it is >>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>GlyphPainter1#viewToModel=>Utilities.getTabbedOffset >>>>> >>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses >>>>> integer arithmetic to get the caret position. >>>>> The same getTabbedOffset uses Font.getStringBounds() which uses >>>>> floating point arithmetic via Rectangle2D.Float. >>>>> >>>>> Proposed fix is to make sure proper floating point getTabbedOffset >>>>> API is used so that floating point calculations is done for char >>>>> width. >>>>> >>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8232243 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.0/ >>>>> >>>>> Regards >>>>> Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From JAYATHIRTH.D.V at ORACLE.COM Wed Apr 29 06:56:23 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Wed, 29 Apr 2020 12:26:23 +0530 Subject: RFR JDK-8169953:JComboBox/8057893: ComboBoxEdited event is not fired! on Windows In-Reply-To: References: Message-ID: +1. Thanks, Jay > On 28-Apr-2020, at 6:37 PM, Prasanta Sadhukhan wrote: > > Hi All, > > This test was added to ProblemList due to it failing on windows and sometimes on mac. > > But I have tried with latest build on local windows and mac system and also on mach5 system (job detail in JBS) where it passed for several iterations > > so we can remove it from ProblemList > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169953 > diff -r 79463a078a39 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Mon Apr 27 10:37:30 2020 +0530 > +++ b/test/jdk/ProblemList.txt Tue Apr 28 18:35:27 2020 +0530 > @@ -780,7 +780,6 @@ > javax/swing/Action/8133039/bug8133039.java 8196089 windows-all,macosx-all > javax/swing/JComboBox/6559152/bug6559152.java 8196090 windows-all,macosx-all > javax/swing/JComboBox/8032878/bug8032878.java 8196092,8196439 windows-all,macosx-all,linux-all > -javax/swing/JComboBox/8057893/bug8057893.java 8169953 windows-all,macosx-all > javax/swing/JComboBox/8072767/bug8072767.java 8196093 windows-all,macosx-all > javax/swing/JComponent/4337267/bug4337267.java 8146451 windows-all > javax/swing/JFileChooser/4524490/bug4524490.java 8042380 generic-all > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From JAYATHIRTH.D.V at ORACLE.COM Wed Apr 29 07:32:11 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Wed, 29 Apr 2020 13:02:11 +0530 Subject: RFR JDK-8232243:Wrong caret position in JTextPane on Windows with a screen resolution > 100% In-Reply-To: <5EA8B795.3060405@oracle.com> References: <8bc45f92-3f5e-ba36-8b24-47e0d46dba02@oracle.com> <5EA36E68.9080403@oracle.com> <5EA449D3.1010307@oracle.com> <5EA8B795.3060405@oracle.com> Message-ID: <60062DFF-CBA7-45A0-806F-2895E630D1AC@ORACLE.COM> +1. Thanks, Jay > On 29-Apr-2020, at 4:39 AM, Philip Race wrote: > > +1 from me. > > -phil. > > On 4/26/20, 9:13 PM, Prasanta Sadhukhan wrote: >> >> Sure..test updated... >> >> http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.2/ Regards >> Prasanta >> On 25-Apr-20 8:01 PM, Philip Race wrote: >>> >>> 96 SwingUtilities.invokeAndWait(() -> createUI()); >>> 97 >>> 98 Point p = textPane.getLocationOnScreen(); >>> 99 Robot robot = new Robot(); >>> >>> For the sake of stability would it be better to create the robot and wait >>> for idle before getting the pane location ? >>> >>> -phil. >>> >>> On 4/24/20, 9:31 PM, Prasanta Sadhukhan wrote: >>>> >>>> Thanks for your review. All comments incorporated >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.1/ Regards >>>> Prasaant >>>> On 25-Apr-20 4:25 AM, Philip Race wrote: >>>>> In the test >>>>> 56 textPane.setFont(new java.awt.Font("Arial", Font.PLAIN, 12)); >>>>> >>>>> you should use a font you know exists. If the idea is that this test is just >>>>> for windows, then @requires windows ? >>>>> >>>>> And >>>>> 94 System.setProperty( "sun.java2d.uiScale", "1.5" ); >>>>> >>>>> should be set as a command line property to the test since that is what we do >>>>> elsewhere, then you can have the test run several times at different scales. >>>>> >>>>> Also currently 1.5 is truncated to 1 except on Windows ... >>>>> >>>>> If you want to test on Linux or Mac you need 2. >>>>> Another reason to use the command line way of doing it. >>>>> >>>>> >>>>> -phil >>>>> >>>>> >>>>> On 4/16/20, 3:16 AM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for an issue where it is seen that, with a screen resolution higher than 100% and then clicking in a JTextPane, the caret (insertion point) is not aligned with the cursor. >>>>>> >>>>>> The issue seems to stem from the fact that caret position calculation in DefaultCaret class utilises API that uses integer calculation than floating point calculations. >>>>>> >>>>>> This issue is in continuation to the fix done for JDK-8199441 where the issue was fixed for JTextArea. [http://hg.openjdk.java.net/jdk/jdk/rev/480c2ae4d031 ] >>>>>> >>>>>> The code flow for JTextArea was >>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset >>>>>> >>>>>> whereas for JTextPane it it is DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>GlyphPainter1#viewToModel=>Utilities.getTabbedOffset >>>>>> >>>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses integer arithmetic to get the caret position. >>>>>> The same getTabbedOffset uses Font.getStringBounds() which uses floating point arithmetic via Rectangle2D.Float. >>>>>> >>>>>> Proposed fix is to make sure proper floating point getTabbedOffset API is used so that floating point calculations is done for char width. >>>>>> >>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8232243 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.0/ >>>>>> >>>>>> Regards >>>>>> Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Apr 29 14:44:20 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 29 Apr 2020 20:14:20 +0530 Subject: RFR JDK-8208566: [TEST_BUG] javax\swing\text\GlyphPainter2\6427244\bug6427244.java: Test failed Message-ID: Hi All, This test was added to ProblemList few months back due to it failing on macOS during nightly testing. But I tried with latest build on local mac and mach5 system (job detail in JBS) where it passed for several iterations, so we can remove it from ProblemList Bug: https://bugs.openjdk.java.net/browse/JDK-8208566 diff -r 04faec1cadb5 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt? Wed Apr 29 14:01:30 2020 +0530 +++ b/test/jdk/ProblemList.txt? Wed Apr 29 20:09:47 2020 +0530 @@ -857,7 +857,6 @@ ?javax/swing/text/StyledEditorKit/4506788/bug4506788.java 8233561 macosx-all ?javax/swing/text/JTextComponent/6361367/bug6361367.java 8233569 macosx-all ?javax/swing/text/html/HTMLEditorKit/5043626/bug5043626.java 233570 macosx-all *-javax/swing/text/GlyphPainter2/6427244/bug6427244.java 8208566 macosx-all* ?javax/swing/ProgressMonitor/ProgressMonitorEscapeKeyPress.java 8233635 macosx-all ?javax/swing/plaf/nimbus/TestNimbusOverride.java 8233559 macosx-all ?javax/swing/JTree/4927934/bug4927934.java 8233550 macosx-all Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Apr 29 20:38:49 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 29 Apr 2020 13:38:49 -0700 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <2e00a232-de21-9724-9eed-bab712696061@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> <7ee86f9f-9b63-ec34-6c42-189661dda3fd@oracle.com> <8a676287-9aed-df8b-4638-c6f809e1336f@oracle.com> <8f3179d4-410a-0cc7-61e4-9773b05e6b43@oracle.com> <2e00a232-de21-9724-9eed-bab712696061@oracle.com> Message-ID: <5EA9E5D9.4020605@oracle.com> 34 import java.awt.*; just for one class : 170 GraphicsConfiguration tipConfig = this.getGraphicsConfiguration(); -phil. On 4/20/20, 11:14 AM, Prasanta Sadhukhan wrote: > > On 20-Apr-20 10:20 PM, Prasanta Sadhukhan wrote: >> >> On 20-Apr-20 10:16 PM, Sergey Bylokhov wrote: >>> On 4/20/20 8:34 am, Prasanta Sadhukhan wrote: >>>> >>>> On 20-Apr-20 8:54 PM, Sergey Bylokhov wrote: >>>>> On 4/20/20 2:40 am, Prasanta Sadhukhan wrote: >>>>>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.4/ >>>>>> >>>>>> used the right GC for the tip but we still need the preferredSize >>>>>> in the paint() >>>>> >>>>> Why do we need it? Do we calculate the size in the >>>>> ToolTipManager.showTipWindow() incorrectly? >>>>> We call tip.getPreferredSize() there, does it return different >>>>> result than in the paint() method? >>>>> >>>> No, there it returns the same value as paint() now after GC fix, >>>> but c.getSize() in paint() returns the JPanel size which is not >>>> same as preferredSize and it is not enough to contain the text, it >>>> seems. >>> >>> But the panel and window both are created by our code in >>> ToolTipManager.showTipWindow, should we adjust it? >>> >> But getPreferredSize() uses span calculation+6 which is not present >> in panel's setSize calculation. I would think using preferredSize is >> better than meddling with setSize calculation, given that >> TooltipManager.showTipWindow () also used getPreferredSize() to >> calculate the tip bounds. > > It seems JPanel (component created for LW popup) GC is again null and > not in sync with JToolTip's GC so in addition to fix JToolTip's GC, we > also need to set GC of JPanel (jn sync with "contents" or tip's GC), > so setSize() will be set same as preferredSize. > > http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.5/ > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Apr 30 02:36:50 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 29 Apr 2020 19:36:50 -0700 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <2e00a232-de21-9724-9eed-bab712696061@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> <7ee86f9f-9b63-ec34-6c42-189661dda3fd@oracle.com> <8a676287-9aed-df8b-4638-c6f809e1336f@oracle.com> <8f3179d4-410a-0cc7-61e4-9773b05e6b43@oracle.com> <2e00a232-de21-9724-9eed-bab712696061@oracle.com> Message-ID: <1cdd53a2-591f-b4d1-b37e-4528f79179f0@oracle.com> On 4/20/20 11:14 am, Prasanta Sadhukhan wrote: > It seems JPanel (component created for LW popup) GC is again null and not in sync with JToolTip's GC so in addition to fix JToolTip's GC, we also need to set GC of JPanel (jn sync with "contents" or tip's GC), so setSize() will be set same as preferredSize. > > http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.5/ I could understand that we need to use some specific GC instead of null(which is the default), but a force to use GC instead of another non-null GC sounds not good, isn't it? -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Apr 30 03:29:58 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Apr 2020 08:59:58 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <1cdd53a2-591f-b4d1-b37e-4528f79179f0@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> <7ee86f9f-9b63-ec34-6c42-189661dda3fd@oracle.com> <8a676287-9aed-df8b-4638-c6f809e1336f@oracle.com> <8f3179d4-410a-0cc7-61e4-9773b05e6b43@oracle.com> <2e00a232-de21-9724-9eed-bab712696061@oracle.com> <1cdd53a2-591f-b4d1-b37e-4528f79179f0@oracle.com> Message-ID: <6b47ac55-41f8-082a-1c13-5ff9590fbba1@oracle.com> On 30-Apr-20 8:06 AM, Sergey Bylokhov wrote: > On 4/20/20 11:14 am, Prasanta Sadhukhan wrote: >> It seems JPanel (component created for LW popup) GC is again null and >> not in sync with JToolTip's GC so in addition to fix JToolTip's GC, >> we also need to set GC of JPanel (jn sync with "contents" or tip's >> GC), so setSize() will be set same as preferredSize. >> >> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.5/ > > I could understand that we need to use some specific GC instead of > null(which is > the default), but a force to use GC instead of another non-null GC > sounds not good, isn't it? > I couldn't get what you are trying to say...You have a problem with using getPreferredSize() in BasicToolTipUI#paint and you asked why can't we use the same setSize() as it is now. I found we cannot use that because JPanel.setSize() is wrong because it's GC was null when the "size" was calculated. If we fix the JPanel's GC with the default GC (the same way we fix ToolTip's GC) then we can continue to use setSize() in paint. If you do not have problem with how we fix JTooltip's GC ,then what is the problem with fixing JPanel's GC? From prasanta.sadhukhan at oracle.com Thu Apr 30 03:51:25 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Apr 2020 09:21:25 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <5EA9E5D9.4020605@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <1d5768ee-ee9e-848a-1dc5-30dad86bddf4@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> <7ee86f9f-9b63-ec34-6c42-189661dda3fd@oracle.com> <8a676287-9aed-df8b-4638-c6f809e1336f@oracle.com> <8f3179d4-410a-0cc7-61e4-9773b05e6b43@oracle.com> <2e00a232-de21-9724-9eed-bab712696061@oracle.com> <5EA9E5D9.4020605@oracle.com> Message-ID: <47893af9-fb8d-f28d-b709-bf5402e2838e@oracle.com> Thanks Phil for your review. It was added to by IDE, anyways rectified it http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.6/ Regards Prasanta On 30-Apr-20 2:08 AM, Philip Race wrote: > 34 import java.awt.*; just for one class : > 170 GraphicsConfiguration tipConfig = this.getGraphicsConfiguration(); > > -phil. > > On 4/20/20, 11:14 AM, Prasanta Sadhukhan wrote: >> >> On 20-Apr-20 10:20 PM, Prasanta Sadhukhan wrote: >>> >>> On 20-Apr-20 10:16 PM, Sergey Bylokhov wrote: >>>> On 4/20/20 8:34 am, Prasanta Sadhukhan wrote: >>>>> >>>>> On 20-Apr-20 8:54 PM, Sergey Bylokhov wrote: >>>>>> On 4/20/20 2:40 am, Prasanta Sadhukhan wrote: >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.4/ >>>>>>> >>>>>>> used the right GC for the tip but we still need the >>>>>>> preferredSize in the paint() >>>>>> >>>>>> Why do we need it? Do we calculate the size in the >>>>>> ToolTipManager.showTipWindow() incorrectly? >>>>>> We call tip.getPreferredSize() there,? does it return different >>>>>> result than in the paint() method? >>>>>> >>>>> No, there it returns the same value as paint() now after GC fix, >>>>> but c.getSize() in paint() returns the JPanel size which is not >>>>> same as preferredSize and it is not enough to contain the text, it >>>>> seems. >>>> >>>> But the panel and window both are created by our code in >>>> ToolTipManager.showTipWindow, should we adjust it? >>>> >>> But getPreferredSize() uses span calculation+6 which is not present >>> in panel's setSize calculation. I would think using preferredSize is >>> better than meddling with setSize calculation, given that >>> TooltipManager.showTipWindow () also used getPreferredSize() to >>> calculate the tip bounds. >> >> It seems JPanel (component created for LW popup) GC is again null and >> not in sync with JToolTip's GC so in addition to fix JToolTip's GC, >> we also need to set GC of JPanel (jn sync with "contents" or tip's >> GC), so setSize() will be set same as preferredSize. >> >> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.5/ >> >> Regards >> Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From JAYATHIRTH.D.V at ORACLE.COM Thu Apr 30 07:05:07 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Thu, 30 Apr 2020 12:35:07 +0530 Subject: RFR JDK-8208566: [TEST_BUG] javax\swing\text\GlyphPainter2\6427244\bug6427244.java: Test failed In-Reply-To: References: Message-ID: <7FB40702-9AB7-4FBD-BF92-B710DE5788C8@ORACLE.COM> +1. Thanks, Jay > On 29-Apr-2020, at 8:14 PM, Prasanta Sadhukhan wrote: > > Hi All, > > This test was added to ProblemList few months back due to it failing on macOS during nightly testing. > > But I tried with latest build on local mac and mach5 system (job detail in JBS) where it passed for several iterations, so we can remove it from ProblemList > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208566 > diff -r 04faec1cadb5 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Wed Apr 29 14:01:30 2020 +0530 > +++ b/test/jdk/ProblemList.txt Wed Apr 29 20:09:47 2020 +0530 > @@ -857,7 +857,6 @@ > javax/swing/text/StyledEditorKit/4506788/bug4506788.java 8233561 macosx-all > javax/swing/text/JTextComponent/6361367/bug6361367.java 8233569 macosx-all > javax/swing/text/html/HTMLEditorKit/5043626/bug5043626.java 233570 macosx-all > -javax/swing/text/GlyphPainter2/6427244/bug6427244.java 8208566 macosx-all > javax/swing/ProgressMonitor/ProgressMonitorEscapeKeyPress.java 8233635 macosx-all > javax/swing/plaf/nimbus/TestNimbusOverride.java 8233559 macosx-all > javax/swing/JTree/4927934/bug4927934.java 8233550 macosx-all > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Apr 30 09:18:27 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 30 Apr 2020 02:18:27 -0700 (PDT) Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <6b47ac55-41f8-082a-1c13-5ff9590fbba1@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> <7ee86f9f-9b63-ec34-6c42-189661dda3fd@oracle.com> <8a676287-9aed-df8b-4638-c6f809e1336f@oracle.com> <8f3179d4-410a-0cc7-61e4-9773b05e6b43@oracle.com> <2e00a232-de21-9724-9eed-bab712696061@oracle.com> <1cdd53a2-591f-b4d1-b37e-4528f79179f0@oracle.com> <6b47ac55-41f8-082a-1c13-5ff9590fbba1@oracle.com> Message-ID: <686539b7-0b4c-ecd9-b5bb-118732854a96@oracle.com> On 4/29/20 8:29 pm, Prasanta Sadhukhan wrote: >> I could understand that we need to use some specific GC instead of null(which is >> the default), but a force to use GC instead of another non-null GC sounds not good, isn't it? >> > I couldn't get what you are trying to say...You have a problem with using getPreferredSize() in BasicToolTipUI#paint and you asked why can't we use the same setSize() as it is now. I found we cannot use that because JPanel.setSize() is wrong because it's GC was null when the "size" was calculated. As I mentioned, in the fix you do not replace the null value, but replace any value if they are not equal to the current screen, is that intentionally? 852 if (component.getGraphicsConfiguration() != 853 contents.getGraphicsConfiguration()) { 854 AWTAccessor.getComponentAccessor(). 855 setGraphicsConfiguration((Component) component, 856 contents.getGraphicsConfiguration()); 857 } If we fix the JPanel's GC with the default GC (the same way we fix ToolTip's GC) then we can continue to use setSize() in paint. If you do not have problem with how we fix JTooltip's GC ,then what is the problem with fixing JPanel's GC? It is unclear why we need to change GC of the panel. In the case of TIP it is needed to calculate the size of the text which is set to the TIP, but the panel does not have any text so why the GC of the panel matters? -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Thu Apr 30 09:42:15 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Apr 2020 15:12:15 +0530 Subject: [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <686539b7-0b4c-ecd9-b5bb-118732854a96@oracle.com> References: <53080f95-f277-06ad-26bd-8435e99dc039@oracle.com> <958266d4-ce7f-f8fa-d3c1-977c55d4ab6a@oracle.com> <94376d72-638e-c2c5-2012-90e90783e391@oracle.com> <96c7d94e-de8d-e108-45e0-0f87b0621f91@oracle.com> <204367cf-916c-1e7a-6b48-3ae09d390b30@oracle.com> <4240f67e-9fe9-9145-7e60-9de0eba713a5@oracle.com> <0122511e-4226-96f8-c1b1-d321bbff78de@oracle.com> <49552a94-8cfe-e482-9e23-af144afdf219@oracle.com> <0d6361ea-b190-c1e0-4c8a-e534ac52f393@oracle.com> <7461e8d4-71a4-8e74-7a79-fb6feb0b7603@oracle.com> <7ee86f9f-9b63-ec34-6c42-189661dda3fd@oracle.com> <8a676287-9aed-df8b-4638-c6f809e1336f@oracle.com> <8f3179d4-410a-0cc7-61e4-9773b05e6b43@oracle.com> <2e00a232-de21-9724-9eed-bab712696061@oracle.com> <1cdd53a2-591f-b4d1-b37e-4528f79179f0@oracle.com> <6b47ac55-41f8-082a-1c13-5ff9590fbba1@oracle.com> <686539b7-0b4c-ecd9-b5bb-118732854a96@oracle.com> Message-ID: <573a165b-b69a-e324-b1ab-28d2b60b4a64@oracle.com> On 30-Apr-20 2:48 PM, Sergey Bylokhov wrote: > On 4/29/20 8:29 pm, Prasanta Sadhukhan wrote: >>> I could understand that we need to use some specific GC instead of >>> null(which is >>> the default), but a force to use GC instead of another non-null GC >>> sounds not good, isn't it? >>> >> I couldn't get what you are trying to say...You have a problem with >> using getPreferredSize() in BasicToolTipUI#paint and you asked why >> can't we use the same setSize() as it is now. I found we cannot use >> that because JPanel.setSize() is wrong because it's GC was null when >> the "size" was calculated. > > As I mentioned, in the fix you do not replace the null value, but > replace any value if they are not equal to the current screen, is that > intentionally? > > ?852???????????? if (component.getGraphicsConfiguration() != > ?853???????????????????? contents.getGraphicsConfiguration()) { > ?854???????????????? AWTAccessor.getComponentAccessor(). > ?855???????????????????????? setGraphicsConfiguration((Component) > component, > ?856 contents.getGraphicsConfiguration()); > ?857???????????? } OK. I now see your point of concern. No, it's not intentional so I have added the null check too http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.7/ > > If we fix the JPanel's GC with the default GC (the same way we fix > ToolTip's GC) then we can continue to use setSize() in paint. If you > do not have problem with how we fix JTooltip's GC ,then what is the > problem with fixing JPanel's GC? > > It is unclear why we need to change GC of the panel. In the case of > TIP it is needed to calculate the size of the text which is set to the > TIP, but the panel does not have any text so why the GC of the panel > matters? > This is because LW popup is nothing but JPanel, as you might already know, so since BasicToolTipUI does not override size (but only override preferredSize, maximumSize, minimumSize) so it actually gives the already created JPanel size, which was wrongly created for NULL GC. > Component createComponent(Component owner) { > JComponent component =new JPanel(new BorderLayout(),true); > > component.setOpaque(true); > return component; > } BasicToolTipUI.java public void paint(Graphics g, JComponent c) { Font font = c.getFont(); FontMetrics metrics = SwingUtilities2.getFontMetrics(c, g, font); Dimension size = c.getSize(); // gets JPanel size Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Apr 30 10:12:45 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 30 Apr 2020 15:42:45 +0530 Subject: RFR JDK-8221902: PIT: javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails on ubuntu Message-ID: <50517454-1ae2-77e8-d150-23ff5243e737@oracle.com> Hi All, Please review a testbug fix for an issue where the test fails on ubuntu in mach5 system. The test has already been modified twice via JDK-8161470 and JDK-8163169 to add waitForIdle() and delay for mac failure, however we still continued to see failure in ubuntu. I added a delay after component.requestFocusInWindow() to allow the component to gain focus. With which the test has passed on several iterations on mach5 ubuntu (job details in JBS) diff -r b5a7999ded93 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt? Thu Apr 30 12:42:03 2020 +0530 +++ b/test/jdk/ProblemList.txt? Thu Apr 30 15:36:24 2020 +0530 @@ -851,7 +851,6 @@ ?javax/swing/JTable/6263446/bug6263446.java 8169959 macosx-all ?javax/swing/JTree/6263446/bug6263446.java 8213125 macosx-all ?javax/swing/JTree/8003400/Test8003400.java 8197560 macosx-all,linux-all *-javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java 8221902 linux-all,macosx-all* ?javax/swing/ToolTipManager/Test6256140.java 8233560 macosx-all ?javax/swing/text/View/8014863/bug8014863.java 8233561 macosx-all ?javax/swing/text/StyledEditorKit/4506788/bug4506788.java 8233561 macosx-all diff -r b5a7999ded93 test/jdk/javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java --- a/test/jdk/javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java Thu Apr 30 12:42:03 2020 +0530 +++ b/test/jdk/javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java Thu Apr 30 15:36:24 2020 +0530 @@ -134,6 +134,8 @@ ???? private static void runTestCase() throws Exception { ???????? focusOn(a); +??????? robot.waitForIdle(); +??????? robot.delay(500); ???????? robot.keyPress(KeyEvent.VK_ENTER); ???????? robot.keyRelease(KeyEvent.VK_ENTER); ???????? robot.waitForIdle(); @@ -189,6 +191,7 @@ ???????????????? | IllegalAccessException e) { ???????????? return false; ???????? } +?????? System.out.println("Testing lookAndFeel " + lookAndFeelString); ???????? return true; ???? } Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: