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 ?
Does that mean this (xinerama centering) is fundamentally unsupportable
on Linux ?
Don't you need to update the docs / referenced spec ?
-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
