<Swing Dev> [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other

Fri Nov 17 00:43:38 UTC 2017

On 16/11/2017 09:05, Alan Snyder wrote:
> I think you are saying that the bound properties can be discovered using 
> an inspector. I would call the inspector a tool.
> 
> My point is that public property notifications are part of the API, and 
> therefore should be documented in the javadoc, as has been done (perhaps 
> incorrectly) for Component.

Yes you are right the "public property notifications are part of the 
API" but in this exact case this notification should be fired only for 
bound properties, and currently "graphicsConfiguration" is not a bound 
property and formally we cannot add it to the javadoc as an example. We 
need to make it bound property and after that we can updated the spec.

> 
> If you are arguing that such information is redundant because it can be 
> discovered from the class, then the same argument would apply to the 
> method signatures. I suspect you would not be in favor of removing 
> method signatures from javadoc. :-)
> 
> On the larger issue, I would say that the issue of supporting HiDPI in 
> applications deserves a section in the tutorial.

I agree and suggest to create a doc bug for this.

> 
>    Alan
> 
> 
> 
> 
>> On Nov 15, 2017, at 9:53 PM, Sergey Bylokhov 
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>>> That is a step in the right direction, but the idea that this public 
>>> and supported property can only be discovered using a tool seems 
>>> wrong to me.
>>
>> This is not a separate tool, it is a class which can operates on java 
>> beans. And the notification which was added in the fix is related to 
>> java beans: java.beans.PropertyChangeListener
>>
>> https://docs.oracle.com/javase/tutorial/javabeans/writing/index.html
>> "Writing beans is simply a matter of following certain coding 
>> conventions. All you have to do is make your class look like a bean — 
>> tools that use beans will be able to recognize and use your bean."
>>
>> Here is an example of the properties and the beans:
>> https://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html
>>
>>> The existing properties are documented under 
>>> Component.addPropertyChangeListener(listener) and 
>>> Component.addPropertyChangeListener(name, listener), although 
>>> unfortunately the lists are not identical.
>>
>> It is not fully correct because it mention a bound properties like 
>> "minimumSize"/"maximumSize" which formally are not a "public" properties.
>> Information about properties can be obtained from the class itself or 
>> from the special bean info class.
>> We have a special com.sun.beans.infos.ComponentBeanInfo class which 
>> contains a list of properties for the Component and I assume it simply 
>> was not updated when implementation of Component was updated(or 
>> updated in one place but not other, etc).
>>
>>> Alan
>>>> On Nov 15, 2017, at 5:10 PM, Sergey Bylokhov 
>>>> <Sergey.Bylokhov at oracle.com 
>>>> <mailto:Sergey.Bylokhov at oracle.com><mailto:Sergey.Bylokhov at oracle.com>> 
>>>> wrote:
>>>>
>>>> On 15/11/2017 08:42, Alan Snyder wrote:
>>>>> If the solution is to listen for changes to the 
>>>>> graphicsConfiguration property, then that property needs to be 
>>>>> documented.
>>>>> If the solution is something else, then what is it?
>>>>
>>>> This new notification is related to the existed old property 
>>>> "graphicsConfiguration". This is an old property because we have 
>>>> getGraphicsConfiguration() method for some time. This fix just make 
>>>> this property "bound".
>>>> But for some reason we made public only a few properties in the 
>>>> Component class like: 
>>>> name,background,foreground,font,enabled,visible,focusable. This can 
>>>> be checked using Introspector class from JavaBeans. I'll take care 
>>>> about this separately, and when it will be reported as a "bound 
>>>> property" the user can assume that this is supported notification.
>>>>
>>>>>   Alan
>>>>>> On Nov 15, 2017, at 8:20 AM, Semyon Sadetsky 
>>>>>> <semyon.sadetsky at oracle.com 
>>>>>> <mailto:semyon.sadetsky at oracle.com><mailto:semyon.sadetsky at oracle.com>> 
>>>>>> wrote:
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 11/14/2017 09:57 PM, Prasanta Sadhukhan wrote:
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> Ok. Updated test to move to 1st screen and then to 2nd screen
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.09/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 11/15/2017 1:38 AM, Sergey Bylokhov wrote:
>>>>>>>> Hi, Prasanta.
>>>>>>>> I checked the test and it fails on my environment, and the 
>>>>>>>> reason is that I have the main screen on the right and the 
>>>>>>>> second screen on the left, which means that the test moves the 
>>>>>>>> window outside of any screens. But it should move the window to 
>>>>>>>> one screen and then to another screen.
>>>>>>>> Small issues "f.dispose();" is called on non-EDT thread.
>>>>>>>>
>>>>>>>> On 13/11/2017 23:58, Prasanta Sadhukhan wrote:
>>>>>>>>> Hi Sergey,
>>>>>>>>>
>>>>>>>>> Updated webrev to use setBounds() instead of robot in test
>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.08/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 11/14/2017 4:13 AM, Sergey Bylokhov wrote:
>>>>>>>>>> Hi, Prasanta.
>>>>>>>>>> I have only comment about the test. Why it uses robot, I think 
>>>>>>>>>> that the setBounds() to another screen should be enough?
>>>>>>>>>>
>>>>>>>>>> On 08/11/2017 23:13, Prasanta Sadhukhan wrote:
>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>
>>>>>>>>>>> Please find updated webrev which changes "graphicsConfig" 
>>>>>>>>>>> notification to "graphicsConfiguration". Added auto test for 
>>>>>>>>>>> this property and also fire the notification after the change.
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.07/
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>>>> On 11/8/2017 11:11 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/8/2017 2:01 AM, Sergey Bylokhov wrote:
>>>>>>>>>>>>> On 07/11/2017 02:55, Prasanta Sadhukhan wrote:
>>>>>>>>>>>>>> AFAIK, all client property are by default "public" and I 
>>>>>>>>>>>>>> do not see any documentation of any other property too. Do 
>>>>>>>>>>>>>> you see any other property being documented in our javadoc?
>>>>>>>>>>>>>
>>>>>>>>>>>>> They are "public" but it does not mean that all of them are 
>>>>>>>>>>>>> specified. Of-course it is unlikely to change, but it 
>>>>>>>>>>>>> should be taken into account.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Small comments about the fix:
>>>>>>>>>>>>>  - Why we fire the notification before the actual change? I 
>>>>>>>>>>>>> suggest to create at least one auto test to check the 
>>>>>>>>>>>>> behavior of new property.
>>>>>>>>>>>> I guess I am firing after the graphicsConfig has been 
>>>>>>>>>>>> changed from what it was last time ie, after
>>>>>>>>>>>> if (graphicsConfig == gc) {
>>>>>>>>>>>>             return false;
>>>>>>>>>>>>         }
>>>>>>>>>>>> If the graphicsConfig has not changed, it will not fire the 
>>>>>>>>>>>> notification.
>>>>>>>>>>>> Also, I amnot sure how to go about this auto test as I am 
>>>>>>>>>>>> not sure how to change graphicsConfig automatically.
>>>>>>>>>>>>>  - What about other classes which call 
>>>>>>>>>>>>> BasicHTML.updateRenderer() in a propertyChange? for 
>>>>>>>>>>>>> example: BasicToolTipUI, SynthToolTipUI, BasicButtonListener.
>>>>>>>>>>>> Yes, these needs to be updated as well.
>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.06/
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>> On 11/7/2017 7:37 AM, Alan Snyder wrote:
>>>>>>>>>>>>>>> Is “graphicsConfig” a new public client property? I don’t 
>>>>>>>>>>>>>>> see it documented anywhere.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think it should be public, or some public equivalent is 
>>>>>>>>>>>>>>> needed, because there are cases where applications need 
>>>>>>>>>>>>>>> to recompute a layout after the graphics configuration 
>>>>>>>>>>>>>>> changes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    Alan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Oct 30, 2017, at 11:12 PM, Prasanta Sadhukhan 
>>>>>>>>>>>>>>>> <prasanta.sadhukhan at oracle.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ok. Modified webrev to make sure data is recalculated by 
>>>>>>>>>>>>>>>> listening to "graphicsConfig" change
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.03/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>
>>
>> --
>> Best regards, Sergey.
> 

-- 
Best regards, Sergey.