Hi Sergey,
Thank you for the comment.
Please find webrev.02.
http://cr.openjdk.java.net/~tnakamura/8234386/webrev.02
Thanks,
Toshio Nakamura
Sergey Bylokhov wrote on 2019/11/22 07:07:03:
> From: Sergey Bylokhov
> To: Toshio 5 Nakamura
> Cc: swing-dev@openjdk.java.net
> Date: 2019/11/22 07:0
It looks like after the .01 version you can inline the usage of
Toolkit.getDefaultToolkit(), it is only used inside
"if (!canPopupOverlapTaskBar()) {".
On 11/21/19 5:10 am, Toshio 5 Nakamura wrote:
Hi Sergey,
Thank you for the review.
How about the fix in webrev.01?
To calculate Insets of defa
Hi Sergey,
Thank you for the review.
How about the fix in webrev.01?
To calculate Insets of default screen could be same as to set gc of default
screen device, I think.
I found similar code in RepaintManager.
http://cr.openjdk.java.net/~tnakamura/8234386/webrev.01
Thanks,
Toshio Nakamura
Serg
Hi Sergey,
<< Is it fine that we pass "-1" to the "adjustWidthHeight"? I am not sure that
it is ready for the negative values(where it calculates proportions). Note that
prepareImage() expects only positive or "-1".
<0. It is
calculating the proportions and also dividing by the passed value. So
That is because the dialog on top of which this backgroundDialog is
shown is also undecorated so that both dialog of same height and there's
no ambiguity of getting wrong dlgPos.
Regards
Prasanta
On 21-Nov-19 2:01 PM, Sergey Bylokhov wrote:
Hi, Prasanta.
What is the reason to change the typ
Hi, Toshio.
In a few lines above your fix, the code takes care of null GC and use the main
screen size as a screen bound, so I think your change should calculate
Insets for the main screen as well instead of using zeros.
BTW probably GraphicsEnvironment.getMaximumWindowBounds() could be used at
Hi, Prasanta.
What is the reason to change the type of the "backgroundDialog" window to
undecorated?
On 11/19/19 12:23 am, Prasanta Sadhukhan wrote:
Hi All,
Please review a testbug fix for a test issue seen to be failing intermittently
in linux nigthly system.
The test iconifies and deicon
On 11/18/19 3:50 am, Pankaj Bansal wrote:
<< You need to read the image to the local var under synchronization and then
get W/H from the local image variable. I guess in this case both W/H will be 0 since
error is occured?
Done. As Alexey pointed, the values are set to -1 when the error occurs.