-
Bug
-
Resolution: Fixed
-
P4
-
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
-
tiger
-
generic, x86, sparc
-
generic, linux, solaris_2.5, solaris_2.5.1, solaris_2.6, solaris_9
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)
======================================================================
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)
======================================================================
- duplicates
-
JDK-4470141 RedHat 7.1: KDE-only: Modal dialogs always placed at the top-left corner.
- Closed
-
JDK-4056038 Dialog boxes are not centered
- Closed
-
JDK-4147333 Frames appear in top left hand corner
- Closed
-
JDK-4145081 jdk 1.1.5 windows pop-up always default position (0,0)
- Closed
-
JDK-4857282 RFE: It is impossible to set no (x,y) position for a window or a frame
- Closed
- relates to
-
JDK-4972974 XAWT: XAllocSizeHints() is called without holding AWT_LOCK
- Resolved
(1 relates to)