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

Thu Nov 16 05:53:26 UTC 2017

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