<AWT Dev> [12] Review Request: 8214918 Unify GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds() across the platforms

[Phil Race]

So the code changes are OK if this is the direction but you pointed 
yourself to where
the existing behaviour was documented, so if that documentation page 
exists still for
current releases, it seems it needs to be updated, and if not you should 
do a release note for this change.

-phil.

On 12/20/18 3:06 PM, Sergey Bylokhov wrote:
> On 20/12/2018 10:57, Phil Race wrote:
>> The synopsis made me think this was refactoring.
>> But when I read it, it seems to be proposing removing the ability to
>> centre a window on a Xinerama desktop, with the principal 
>> justification that
>> this was only ever something that worked on Solaris.> Is this 
>> absolutely necessary ?
>
> Yes, I would like to drop it as it causes some surprising behavior, 
> when the
> window is opened somewhere out of the main screen.
> I have reopened the similar bug for the splash screen:
> https://bugs.openjdk.java.net/browse/JDK-6481523
>
> At some point we should follow this logic:
>  - By default use the main screen for the window/splash(even better 
> the screen where the app was run)
>  - The user may customize it by the "XINERAMA_CENTER_HINT" atom.
>
>> Does that mean this (xinerama centering) is fundamentally 
>> unsupportable on Linux ?
>
> It is possible to implement even on windows/mac but we should not by 
> default
> open the windows in between of screens.
>
>> Don't you need to update the docs / referenced spec ?
>
> It was a Solaris only implementation, and guess we have no strict 
> specification
> on how it should work.
>
>>
>> -phil.
>>
>>
>> On 12/6/18 9:26 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 12.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214918
>>> Webrev: http://cr.openjdk.java.net/~serb/8214918/webrev.00
>>>
>>> In the fix for JDK-8076313 I need to implement possibility of switch 
>>> between xinerama and non-xinerama modes at runtime. As a separate 
>>> part I would like to investigate the usage of 
>>> X11GraphicsEnvironment.runningXinerama() and replace it by some 
>>> other generic for single/multi-screen solution.
>>>
>>> This bug is about one of the place where the flag above is used.
>>>
>>> In jdk 1.4 two new methods were added to the GraphicsEnvironment class:
>>>  - getCenterPoint()
>>>  - getMaximumWindowBounds()
>>> see 
>>> https://docs.oracle.com/javase/7/docs/technotes/guides/awt/1.4/AWTChanges.html#windowCentering
>>>
>>> Take a look to this descriptions from the link above:
>>> "X-Window, Xinerama
>>> All monitors share a single virtual coordinate space, as on 
>>> Microsoft Windows. However, it is possible for the user to specify 
>>> through X resources where windows should be centered. If these 
>>> resources are set, getCenterPoint reflects their value. Otherwise, 
>>> it returns the point at the center of the virtual coordinate space. 
>>> (In practice, this will almost always be set - CDE sets it by 
>>> default.)"
>>>
>>> Since the case above was implemented on the Solaris, and uses an 
>>> extension of the xinerama, I suggest to remove this and align 
>>> implementation across the platforms:
>>>  - getCenterPoint returns the coordinates of the center of the 
>>> primary display for all platforms
>>>  - getMaximumWindowBounds returns the bounds of the primary display 
>>> minus display insets for all platforms
>>>
>>>
>>
>
>