It seems I missed that point in the discussion. I agree the documenting
the new property make sense because of its importance for HiDPI.
--Semyon
On 11/15/2017 08:42 AM, Alan Snyder wrote:
It is great to have this problem fixed for the JDK provided components, but
what is the solution for application developers who need to update custom
layouts when the graphics configuration changes?
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?
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
