Hi Oleg,
I am just curious about adding rootBounds.x and rootBounds.y, it looks
redundant to me.
Is there a case when a root window have coordinates with non-zero values?
MultiScreenInsetsTest.java:
62 if ((bounds.x != 0 && insets.left >= bounds.x)
63 || (bounds.y != 0 && insets.top >= bounds.y)) {
This check will fail for screen with
[x=1000,y=50,width=1000,height=1000] bounds and top inset 100,
but it is a valid case.
I think we should check insets against screen width and height:
if (insets.left >= bounds.width
|| insets.right >= bounds.width
|| insets.top >= bounds.height
|| insets.bottom >= bounds.height) {
Otherwise fix looks good to me.
Thanks,
Alexander.
On 02/04/2014 10:26 AM, Oleg Pekhovskiy wrote:
Hi All,
please review the second version of fix:
http://cr.openjdk.java.net/~bagiras/8020443.2/
It turned out that struts must be checked and corrected from all sides
to become the proper screen insets.
Thanks,
Oleg
On 01/21/2014 06:31 PM, Oleg Pekhovskiy wrote:
Hi all,
please review the fix
http://cr.openjdk.java.net/~bagiras/8020443.1/
for
https://bugs.openjdk.java.net/browse/JDK-8020443
Referring to the standards, we must calculate insets the special way
for Xinerama:
http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html
_NET_WM_STRUT_PARTIAL
"The start and end values associated with each strut allow areas to
be reserved which do not span the entire width or height of the
screen. Struts MUST be specified in root window coordinates, that is,
they are /not/ relative to the edges of any view port or Xinerama
monitor."
So the fix checks if the insets have absolute values and if so makes
them relative to each screen.
The issue occurred when the Frame was created with the location by
default.
Thanks,
Oleg
