-
Bug
-
Resolution: Fixed
-
P4
-
1.1.1
-
None
-
1.1.5
-
sparc
-
solaris_2.5.1
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2014649 | 1.2.0 | Paul Young | P4 | Resolved | Fixed | 1.2beta2 |
JDK 1.1.1D
The Motif implementation of reshape() has some questionable code
which attempts to prevent the underlying widget from being moved to the
location 0, 0. The following code from awt_util.c:awt_util_reshape() is
at fault (line 136):
> /* GES: AVH's hack:
> * Motif ignores attempts to move a toplevel window to 0,0.
> * Instead we set the position to 1,1. The expected value is
> * returned by Frame.getBounds() since it uses the internally
> * held rectangle rather than querying the peer.
> */
> if ((x == 0) && (y == 0)) {
> XtVaSetValues(w, XmNx, 1, XmNy, 1, NULL);
> }
The code then goes on to reset the location and size if they have changed, but
under some circumstances the widget will be left at position 1, 1 even though
it should be moved to 0, 0.
The comment seems to indicate that this code is necessary for toplevel windows.
However, this workaround is being applied generically to all components, not
just toplevel windows. Since it is definitely possible to move a Motif
widget to 0, 0, perhaps a test for the widget class should be performed in
order to limit this workaround to toplevel shells.
Moving the widget to 1, 1 causes all sorts of problems with component layout.
For example, the widget may overlap and thus clip any siblings located below
or to the right. The component itself may be unnecessarily clipped by its
siblings or parent. And, of course, the component's location will appear
off by one, even though AWT reports the location correctly when queried.
The following applet can be used to reproduce the problem:
-------------------------------------------------------------------------------
import java.applet.Applet;
import java.awt.BorderLayout;
import java.awt.Canvas;
import java.awt.Color;
/*
* This applet can be used to reproduce problems with the Motif AWT reshape
* implementation. Resizing the applet window causes the canvas to be
* moved to 1, 1, even though it is always programatically set to 0, 0 by
* the BorderLayout layout manager. After resizing the window, you will be
* able to see the red applet panel at the top and left edges.
*
* Use the following HTML code to run the applet:
* <applet code="ReshapeBug.class" width=200 height=200></applet>
*/
public class ReshapeBug extends Applet
{
public void init()
{
// Create a white canvas
Canvas canvas = new Canvas();
canvas.setBackground(Color.white);
// Use border layout with canvas in the center so that the canvas will be
// resized to cover the entire applet.
setLayout(new BorderLayout());
add("Center", canvas);
// Setting applet's background to red. Should never be able to see the
// applet, since the canvas child covers the entire applet, but upon
// resizing the applet's window, the red applet panel can be seen.
setBackground(Color.red);
}
}
The Motif implementation of reshape() has some questionable code
which attempts to prevent the underlying widget from being moved to the
location 0, 0. The following code from awt_util.c:awt_util_reshape() is
at fault (line 136):
> /* GES: AVH's hack:
> * Motif ignores attempts to move a toplevel window to 0,0.
> * Instead we set the position to 1,1. The expected value is
> * returned by Frame.getBounds() since it uses the internally
> * held rectangle rather than querying the peer.
> */
> if ((x == 0) && (y == 0)) {
> XtVaSetValues(w, XmNx, 1, XmNy, 1, NULL);
> }
The code then goes on to reset the location and size if they have changed, but
under some circumstances the widget will be left at position 1, 1 even though
it should be moved to 0, 0.
The comment seems to indicate that this code is necessary for toplevel windows.
However, this workaround is being applied generically to all components, not
just toplevel windows. Since it is definitely possible to move a Motif
widget to 0, 0, perhaps a test for the widget class should be performed in
order to limit this workaround to toplevel shells.
Moving the widget to 1, 1 causes all sorts of problems with component layout.
For example, the widget may overlap and thus clip any siblings located below
or to the right. The component itself may be unnecessarily clipped by its
siblings or parent. And, of course, the component's location will appear
off by one, even though AWT reports the location correctly when queried.
The following applet can be used to reproduce the problem:
-------------------------------------------------------------------------------
import java.applet.Applet;
import java.awt.BorderLayout;
import java.awt.Canvas;
import java.awt.Color;
/*
* This applet can be used to reproduce problems with the Motif AWT reshape
* implementation. Resizing the applet window causes the canvas to be
* moved to 1, 1, even though it is always programatically set to 0, 0 by
* the BorderLayout layout manager. After resizing the window, you will be
* able to see the red applet panel at the top and left edges.
*
* Use the following HTML code to run the applet:
* <applet code="ReshapeBug.class" width=200 height=200></applet>
*/
public class ReshapeBug extends Applet
{
public void init()
{
// Create a white canvas
Canvas canvas = new Canvas();
canvas.setBackground(Color.white);
// Use border layout with canvas in the center so that the canvas will be
// resized to cover the entire applet.
setLayout(new BorderLayout());
add("Center", canvas);
// Setting applet's background to red. Should never be able to see the
// applet, since the canvas child covers the entire applet, but upon
// resizing the applet's window, the red applet panel can be seen.
setBackground(Color.red);
}
}
- backported by
-
JDK-2014649 Widget location is set to 1, 1 when moving it to 0, 0
-
- Resolved
-