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

[Semyon Sadetsky]

On 11/25/2016 4:13 PM, Sergey Bylokhov wrote:
> On 24.11.16 22:21, Semyon Sadetsky wrote:
>>>>> All robots may be used to address any area of the desktop 
>>>>> regardless of
>>>>> the screen constructor argument.
>>>>> The coordinate system is the only aspect the screen argument affects.
>>>>
>>>> This statement means that this constructor will have any effects when
>>>> used for the system where each screen "use different coordinate 
>>>> systems
>>>> to act as independent screens" this is not true for windows. It is 
>>>> true
>>>> only for the screens on unix when each screen will have its own
>>>> coordinate space, and which space will be used depends from on what
>>>> screen the robot was created.
>>>
>>> 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 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 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.
>
>> 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.
>
>