On 11/15/2017 09:53 PM, Sergey Bylokhov 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).
Anyway it is worth to mention separately that the graphicsConfiguration
property change notification is important for HiDPI text layout because
this is not trivial and may save a lot of time to developer.
Alan
On Nov 15, 2017, at 5:10 PM, Sergey Bylokhov
<sergey.bylok...@oracle.com <mailto: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 <mailto: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.
