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

[Semyon Sadetsky]

On 11/29/2016 6:09 PM, Sergey Bylokhov 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.
>
>>> The whole application will use the coordinate system of the second
>>> monitor, because this is separate standalone screen.
>>>
>>>> The same app can be run on the usual extended desktop and then 
>>>> moved to
>>>> the second screen. In this case, the robot created for the current
>>>> screen should act in 2nd screen coordinates as well, otherwise 
>>>> behavior
>>>> of the app would be different and depend on the native platform
>>>> configuration.
>>>
>>> The robot should always use the coordinate system of the screen, in
>>> the same way as TopLevel windows use it.
>> Where is this specified? Is the "TopLevel window" available to user
>> through any java API?
>
> "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.
>
>>>>>> 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.
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>