JDK-6177452 : setLocationRelativeTo() places the window incorrectly on multi-mon-xinerama when comp is invisible
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux_redhat_9.0
  • CPU: generic,x86
  • Submitted: 2004-10-12
  • Updated: 2017-05-16
  • Resolved: 2005-03-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b27Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
I am calling window.setLocationRelativeTo() with a component that is invisible. According to the specification, this method is supposed to place the window at the center of the screen when the given component is null or invisible. This actually behaves differently on different platforms, on a multi-monitor system. 

On Windows with virtual screen, the window is getting placed at the center of the primary display.
On Linux with xinerama (virtual screen), the window is getting placed at the center of the virtual screen. The specification does not say anything about how this would work on a virtual screen setup. 

This behavioral difference is due to the code given below:
setLocation((screenSize.width - paneSize.width) / 2,
           (screenSize.height - paneSize.height) / 2);
Here the screen size is obtained by calling Toolkit.getScreenSize(). This method behaves differently on win32 and xinerama. on Win32, it returns the size of the prim display but on xinerama it returns the size of the virtual screen. Hence the window also gets centered accordingly. (A bug is filed against this method: 5100801 which is evaluated as a doc bug)

What i am expecting here is to have a uniform approach across all virtual screen setups, be it xinerama or win32. 
1. If the intention is to place with window at the center of the virtual screen, it must be done for both the cases - win32 as well as xinerama. 

2. Alternatively setLocationRelativeTo() can use Window centering APIs (GraphicsEnv.getCenterPoint()) to center the window within the primary display. This method works consistently across all setups.

3. Another option is, the 2 cases such as component being null and component being invisible can be handled differently. When the component is null, it can use option-2. If the component is invisible, GraphicsConfig can be obtained from the invisible component and the window can be centered within the monitor where the invisible component is located. 

The specification must be enhanced to clarify this for a multi-monitor scenario (virtual screen as well as independent screens). 

I have attached a sample test which shows a message dialog using JOptionPane. It covers both the cases where the component is null and the component is invisible. Run it on a win32 - virtual screen setup as well as on a linux-xinerama setup. If the window is placed at the center of the virtual screen on xinerama, the bug is reproduced.
###@###.### 10/12/04 06:45 GMT

Comments
EVALUATION The JavaDoc for this method should be changed to reflect what does the "center of the screen" mean. The best way to derermine the center is GraphicsEnvironment.getCenterPoint(). It returns the center of the primary screen for windows or linux w/o xinerama, and the center of the whole virtual display for xinerama. On Solaris, if a hint XINERAMA_CENTER_HINT is set for the root window, the method also takes it into consideration. ###@###.### 2005-1-25 11:50:34 GMT
25-01-2005