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.
The existing properties are documented under Component.addPropertyChangeListener(listener) and Component.addPropertyChangeListener(name, listener), although unfortunately the lists are not identical. Alan > On Nov 15, 2017, at 5:10 PM, Sergey Bylokhov <sergey.bylok...@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.sadet...@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.sadhuk...@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.
