United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4102292 : New AWT Frame w/o coordinates always pops up in upper left hand screen location.

Details
Type:
Bug
Submit Date:
1998-01-07
Status:
Resolved
Updated Date:
2003-08-19
Project Name:
JDK
Resolved Date:
2003-08-19
Component:
client-libs
OS:
solaris_9,solaris_2.5,solaris_2.6,solaris_2.5.1,linux,generic
Sub-Component:
java.awt
CPU:
x86,sparc,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
solaris_2.6,1.1,1.1.5,1.1.6,1.2.0,1.2.2,1.3.0,1.4.0,1.4.1
Fixed Versions:
5.0 (tiger)

Related Reports
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:

Sub Tasks

Description
Between JDK1.1.4 and JDK1.1.5 on the Solaris 2.5.1 platform the behavior of the AWT changed in an unfavorable way. An initial Frame whose coordinates aren't specified can no longer be located on the window system by the window manager without the application specifying exact coordinates for the new window. The desired behavior is to have the window manager tile new windows and not require the application programmer to have to add this type of logic to their code.  

In previous JDK versions, the underlying default window manager position was used which resulted in a tiling of new windows as they were created. In JDK1.1.5, the window's initial screen position is always in the upper left hand corner of the screen resulting in overlapping windows when multiple instances of applications are started. The overlapping window condition is very undesirable from a user-interface standpoint as the user is potentially unaware that more than the top window exists and they also have to always manually move their windows on their desktop to a suitable location.  

Verification on WindowsNT and Windows95: (Done by Ralph Karr, JavaSoft CTE)

Using JDK 1.1.2, 1.1.3, 1.1.4 and 1.1.5 the window initially always shows up at upper left hand screen position and getBounds() reports this position correctly.  
Using JDK 1.0.2 the windows initial position is determined by the underlying default window manager and getBounds() reports whatever the position is, correctly.  

Verification on Solaris 2.5.1 (CDE): (also done by Ralph Karr, JavaSoft CTE)

Using JDK 1.0.2, 1.1.2, 1.1.3 and 1.1.4 the windows initial position determined by the underlying default window manager and getBounds() reports a wrong position of (0,0).  Using JDK 1.1.5 the window initially always shows up at the upper left hand screen position and getBounds() reports this position correctly. 

For more background, please reference CTE Escallation 511847. 

Name: krT82822			Date: 03/10/2000


java version "1.2.2"
Classic VM (build 1.2.2-L, green threads, nojit)


Same bug as #4102292 - except there is no mention of these specific window
managers: Sawmill, Enlightenment.  These window managers are becoming very
popular, and are being used under the GNOME desktop.  For many Linux newbies,
this will be the default.

The problem:
Start any JFrame app that doesn't specify the initial window position (which
means the OS/window manager should pick one).  (The Notepad demo app does this.)
The JFrame appears at 0,0 with the titlebar and left edge of the frame off
screen - which means you can't move the window (unless you are using virtual
desktops.)

No matter what the selections are in the window manager, this is where the
window is placed.  Interactive/non-interactive doesn't matter.  The window is
just blindly placed there.
(Review ID: 102327)
======================================================================

                                    

Comments
EVALUATION

The problem is that the AWT currently has no internal mechanism to
determine whether the 0,0 location of the window was set by the program
or just there by default (because no location was set).

It is true that the default location for a window should be a platform-
dependent value (this is especially important for X11, where different
window managers might have different policies about window placement).
The AWT would need to track whether or not the location was "set" by
the program (using a bit flag) and if it wasn't it should just allow
the window to "default" to whatever location is appropriate for the
platform. (and once the window is mapped to the screen, the location
value in the Window object should be updated to reflect that value).

amy.fowler@Eng 1998-09-29

06/28/1999 sandeepk@eng: Tested the user reported bug under Solaris 2.6 with JDK 1.2.2. The bug is reproducible.

One suggestion for a solution would be to have a system property that is set to the intended default behavior.  Another suggestion would be to provide a pluggable interface for managing window placement (something like Swing's PLAF).
Window placement management is predominantly aesthetic and requires a heuristic solution.
michael.martak@Eng 1999-08-10

Commit to Tiger
###@###.### 2001-09-28

This does not require an API change and should at least be partly fixed for hopper (top priority).
###@###.### 2001-11-08 

Deferred to Mantis or Tiger, depending on resources.  
###@###.### 2002-07-24

Recent discussions seem to imply that we need an API change to handle this 
correctly, which means it cannot be done before Tiger.  
###@###.### 2002-11-07
                                     
2002-07-24
PUBLIC COMMENTS

New AWT Frame with no specified initial coordinates always pops up in upper left hand screen location. This behavior is different than previous versions of the JDK.  
                                     
2004-06-10
SUGGESTED FIX

Allow the window manager to pick initial Frame locations which tile along with the rest of the windows on the desktop. Don't use the upper left hand screen position as the default if the application doesn't specify an initial location with setLocation() method. 
                                     
2004-06-11
WORK AROUND

One suggested workaround was to pick an initial window position in the middle of the screen somewhere. Subsequent window positions can now be calculated and positioned at absolute locations based on an offset from the initial window's position. This offset would be enough to allow the title bar that the window manager adds to be visible.  

This workaround pushes functionality of the window manager down into the application where it should not be. Customers don't like to have to do this and it not a good solution to have to present to them.   

Name: krT82822			Date: 03/10/2000


(Review ID: 102327)
======================================================================
                                     
2004-06-11
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b16


                                     
2004-06-14



Hardware and Software, Engineered to Work Together