<AWT Dev> [9] Review request for 8169133: This time, on Windows: java/awt/Robot/SpuriousMouseEvents/SpuriousMouseEvents.java

[Sergey Bylokhov]

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.