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

[Semyon Sadetsky]

On 11/28/2016 11:13 PM, Sergey Bylokhov wrote:

> On 25.11.16 17:08, Semyon Sadetsky wrote:
>>>>> Then JDK-8013116 was fixed the request for specification update was
>>>>> created: https://bugs.openjdk.java.net/browse/JDK-8033128
>>>> Different coordinate system simply means different coordinate origins.
>>>> This is the most natural behavior for the robot created for certain
>>>> screen.
>>>
>>> And if both screens have the same coordinate system simply means that
>>> they have same coordinate origins.
>> They may share the same extended screen coordinates but have different
>> origins.
>
> 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.
>
>> If you switch off Xinerama on Linux, not sure that this is well
>> supported by default desktop shell, anyway, then you can run an app on
>> the second monitor using DISPLAY=:0.1.
>> If this app creates robot for the current screen it acts in the 2nd
>> screen coordinates according to the spec.
>
> 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?
>
>>>
>>>> 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.
>>>
>>>
>>
>
>