On 29.11.16 19:18, Semyon Sadetsky wrote:
On 29.11.16 17:47, Semyon Sadetsky wrote:
If the same coordinate system is shared by both screens, means that
each point passed to the robot will be related to the(0,0). It is not
necessary the (left/top) point of the screen because the screen itself
can be shifted from the (0,0)/
That would mean that both coordinate systems are equivalent and belong
to the main screen. But requested robot should belong to the screen
pointed by the constructor argument.
It should belong to the screen *coordinate system*. The starting point
of the coordinate system is (0,0). If two screens share coordinate
space mean that there are no differences on which screen the robot was
created.
For that case one need to use the robot which was created by no-arg
constructor. For the specific screen robot its origin should be the
screen origin because only in this case an application used such robot
will act equally on extended and separated screens.
no-arg constructor will create the robot on the main/default screen. The
constructor in question will create the robot on the specific screen and
the Robot will use the coordinate space of screen where it was created.
"TopLevel window" are Frames, Windows, etc. the API is
Component.getLocationOnScreen();
This API is a screen unaware and only compatible with the robot without
screen attribute.
Of course it is a screen aware:
" * Gets the location of this component in the form of a point
* specifying the component's top-left corner in the screen's
* coordinate space."
public Point getLocationOnScreen() {}
This method returns the point in the screen's coordinate space. It also
have a constructor which allows to create the Frame on the specific
screen. But if two screens shares the same coordinate space then
getLocationOnScreen() will return the same point without dependency on
the screen on which the frame was created.
I didn't see a desktop within the OSes supported by JDK9 where
multiple
screens are treated as a separate displays rather then one extended
desktop.
Such configurations exists, even if default configs supported by
Oracle have Xinerama does not mean that it was not supported in past,
and is not supported by OpenJDK in general.
It seems JDK-8013116 should be reworked to correspond to the current
state of multiscreen concept on the supported platforms.
--
Best regards, Sergey.
