United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4401846 : fvwm/fvwm2: Frame's title bar, icons appear offscreen [content pane is at (0,0)]

Details
Type:
Bug
Submit Date:
2001-01-04
Status:
Resolved
Updated Date:
2003-08-21
Project Name:
JDK
Resolved Date:
2003-08-20
Component:
client-libs
OS:
solaris_8,solaris_7,linux
Sub-Component:
java.awt
CPU:
x86,sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.3.0,1.4.0
Fixed Versions:
5.0 (tiger)

Related Reports
Duplicate:

Sub Tasks

Description
orig synopsis:  "Jpanel Appears on screen with wm icons and title off screen (fvwm and fcwm2)"

Name: boT120536			Date: 01/04/2001


java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)


import javax.swing.*;
import java.awt.*;
import java.awt.event.*;


public class SimpleButtonExample2 extends JFrame implements ActionListener {

    private String labPrefix = "Number of button clicks: ";
    private int numClicks = 0;
    private JLabel label = new JLabel(labPrefix + "0  ");


    public SimpleButtonExample2 () {
        super("Simple Button Example");

        JButton qbutton = new JButton("Quit");
        qbutton.addActionListener(new QuitButtonListener());



        JButton cbutton = new JButton("Press Me");
        cbutton.addActionListener(this);
        cbutton.setActionCommand("PressMe");

        JButton cbutton2 = new JButton("Another");
        cbutton2.setActionCommand("Another");
        cbutton2.addActionListener(this);

        // Create a panel to place the buttons onto
        JPanel pane = new JPanel();
        pane.add(qbutton);
        pane.add(cbutton);
        pane.add(cbutton2);
        pane.add(label);

        // now add the panel to the content pane of the frame
        this.getContentPane().add(pane);
        this.pack();
        this.setVisible(true);

    }

    public void actionPerformed(ActionEvent e) {

        if (e.getActionCommand().equals("PressMe")) {
           numClicks++;
           label.setText(labPrefix + numClicks);
        } else {
           // Trying out the key-mask

           System.out.println("Another button pressed");
        }

    }

    public static void main(String[] args) {
        SimpleButtonExample2 app = new SimpleButtonExample2();
    }

// INNER CLASS

    class QuitButtonListener implements ActionListener {
        public void actionPerformed(ActionEvent e) {
                System.exit(0);
        }
}

}

Window Manager Title and buttons not on screen, when java SimpleButtonExample2
is started.
 
It seems to place the window and then it is repositioned with the title etc off
screen.

Seems to work ok with sawmill and twm it does not exibit the problem however
fvwm and fvwm2 do.

Solaris 7 and 8 tried with jdks 1.3.0 1.3.0_01 problem does not occur with
jdk 1.2.1_04
Not repeatble on linux 1.3.0_01 and 1.2.2.
(Review ID: 114578) 
======================================================================

                                    

Comments
EVALUATION

According to the report, it sounds like this test works fine with Sawfish and 
dtwm, and has problems only with fvwm and fvwm2.  
eric.hawkes@eng 2001-01-04

See also 4457472.  Commit to fix in Tiger.  
eric.hawkes@eng 2001-05-18

Reproducible on build 1.4.0-beta_refresh-b70.
mike.bronson@eng 2001-07-11

Name: vuR10080			Date: 08/02/2002

###@###.###  2002-08-02

This is an fvwm2 bug, it ignores gravity when handling ConfigureRequest's.

$ wish
% wm geometry .
200x200+0+0
% wm geometry . +1+1

That request to move window to +1+1 will move the window title off-screen.

We have a code to work around this problem that is activated for E!
and IceWM, but I feel this is the wrong thing to do - when the gravity
bug is fixed, the workaround will cause problems.  Since there are
several popular WMs with this bug, perhaphs the workaround shall be
conditionalized on a property or an environment variable.

======================================================================

Name: vuR10080			Date: 08/06/2002

###@###.###  2002-08-06

A reply from Dominik Vogt <###@###.###>:

| To resolve that issue, there is only one way that works:  Don't
| change the window position after the window was mapped.   Let me
| explain the reason behind this.
|
| Like most of the problems where the application and the WM
| disagree, it starts with the ICCCM2.  In the section about initial
| window hints (4.1.2.3) describes how to interpret the wanted
| position and gravity:
|
|   The win_gravity may be any of the values specified for
|   WINGRAVITY in the core protocol except for Unmap :
|   [snip]
|   It specifies how and whether the client window wants to be
|   shifted to make room for the window manager frame.
|
| This is what you expect to happen in a ConfigureRequest too, and
| this interpretation is indeed backed by the ICCCM2 in section
| 4.1.5:
|
|   ...
|   The border width to be used and win_gravity position hint to be
|   used are those most recently requested by the client. Client
|   configure requests are interpreted by the window manager in the
|   same manner as the initial window geometry mapped from the
|   Withdrawn state, as described in section 4.1.2.3.
|   ...
|
| So much for the theory.  In real life, this rule is ignored more
| often than honoured for several reasons:
|
|  1) A lot of application developers never read the ICCCM2.
|  2) Many of those who did probably never noticed the well hidden
|     implications about window placement.
|  3) The man page for XMoveWindow uses slang that is misleading
|     and never defined:
|
|       The x and y members are used to set the window's x and y
|       coordinates, which are relative to the parent's origin and
|       indicate the position of the upper-left outer corner of
|       the window.
|
|     This sounds as if the top left corner gets the requested
|     position, but it means that the top left pixel of the window
|     border is placed at said position.  It can be easily
|     misunderstood.
|  4) The ICCCM2 rule is just plain inconvenient:  If an application
|     uses e.g. XMoveResizeWindow(), it has to find out the position
|     of the WM frame first, which is no easy task (unless you read
|     the ICCCM2 carefully and know about the WM_STATE atom).  Many
|     applications use XMoveResizeWindow() even if the window did
|     not move.  It's much more convenient to just set the current
|     window position again in that request.  In theory, the same
|     effect would better have been achieved with StaticGravity, but
|     then the user can override gravity in the .Xdefaults, so that
|     wouldn't help.
|  5) Some applications totally freak out when the ICCCM2 rule is
|     followed.  They may set their position again and again, slowly
|     moving themselves off screen.
|
| To sum it up:  it started with lousy documentation being
| misinterpreted and then got out of hand.  A few years ago, window
| managers that followed the ICCCM2 rule were considered buggy.  But
| then came KDE, GNOME and Java, ignoring that tradition and clinged
| to the letters of the ICCCM2.  Nowadays we have many, many old
| school window managers that don't work well with Java and a few
| new window managers that do.  Ironically, I believe that Java is
| the the main reason for that move towards honouring the spec.
|
| To sum up the summary:  the set of all window managers is split
| into two factions, one that ignores the ICCCM2 and one that
| honours it.  Now that this is a fact, an application that wants to
| behave has several options:
|
|  * Implement highly sophisticated heuristics to guess which way
|    the window manager works.  This probably involves creating a
|    test window and moving it around, but whatever you do, you can
|    always make a mistake.  For example if the window manager does
|    not allow that the application moves some of its windows (fvwm
|    has an option for this).  Or if the user choses a different
|    desktop theme that changes the size of the window decorations.
|    This is the approach Java has taken with the hard coded MWM
|    handling.  In general it's unreliable.
|
|  * Never move its windows.  This is an easy to implement solution.
|    Many users would appreciate this.  There are only few things
|    more annoying than applications that know better than the user
|    where their windows should be placed.  You may think this
|    position is somewhat strict.  But in the end, the *window
|    manager* is resposible for window placement, not the
|    application.
|
|  * Withdraw the window, then move it, then map it again.  This
|    solution is sub optimal for two reasons:  It causes the window
|    to flicker and, worse, lets the window manager place the window
|    from scratch.  If program specified placement is disabled
|    (which is a frequently used option in window managers), the
|    window ends up in a random position.  And no, using the
|    USPosition hint is no solution because it's (a) forbidden by
|    the ICCCM2 and (b) the user can chose to override this option
|    too.  Overall, I'd not recommend this solution.
|
| I'm willing to provide any assistance to resolve this issue.  Just
| contact the mailing list (###@###.###).

====================================================================== 

AWT already can deal with both WM behaviors but need a way to detect
if the running WM implements strict ICCCM behavior or StaticGravity
behavior.
 
AWT already tries to detect some of the WMs that are known to
implement the StaticGravity behavior, but this approach doesn't scale
well.  Unfortunately there's no standardized (neither de-jure, nor
de-facto) way to detect at run time which behavior the window manager
implements.
 
We propose to introduce an environment variable
_JAVA_AWT_WM_STATIC_GRAVITY that a user can set to indicate that his
window manager implements StaticGravity behavior.

This will be available in J2SE 1.5.  
###@###.### 2003-08-21

The Activity Rating is High for FVWM at http://www.plig.org/xwinman/fvwm.html
This bug has been fixed in MToolkit, but *not* in XToolkit.
Since XToolkit will be the default on Linux, I think this bug
should also be fixed on XToolkit. It should be taken out of the
Integrated state until it is Integrated into XToolkit, the default
AWT Toolkit for J2SE 1.5 on Linux.

###@###.### 2003-09-29

I have ported the fix to XAWT. See suggested fix for details.

###@###.### 2003-10-21
                                     
2003-09-29
SUGGESTED FIX

*** /export/bino/t1/webrev/src/solaris/classes/sun/awt/X11/XToolkit.java-       Tue Oct 21 14:38:03 2003
--- XToolkit.java       Tue Oct 21 13:55:58 2003
--------------------------------------------------------------------------------
*** 286,295 ****
--- 286,298 ----
          } else {
              return val;
          }
      }
  
+     static native String getEnv(String key);
+ 
+ 
      static String getAWTAppClassName() {
          return awtAppClassName;
      }
  
      public static final String DATA_TRANSFERER_CLASS_NAME = "sun.awt.X11.XDataTransferer";




*** /export/bino/t1/webrev/src/solaris/classes/sun/awt/X11/XWM.java-    Tue Oct 21 14:38:03 2003
--- XWM.java    Tue Oct 21 13:45:46 2003
--------------------------------------------------------------------------------
*** 1208,1219 ****
--- 1208,1234 ----
      }
      /*
       * Some buggy WMs ignore window gravity when processing
       * ConfigureRequest and position window as if the gravity is Static.
       * We work around this in MWindowPeer.pReshape().
+      *
+      * Starting with 1.5 we have introduced an Environment variable 
+      * _JAVA_AWT_WM_STATIC_GRAVITY that can be set to indicate to Java
+      * explicitly that the WM has this behaviour, example is FVWM.
       */
+ 
+     static int awtWMStaticGravity = -1;
      static boolean configureGravityBuggy() {
+ 
+         if (awtWMStaticGravity == -1) {
+             awtWMStaticGravity = (XToolkit.getEnv("_JAVA_AWT_WM_STATIC_GRAVITY") != null) ? 1 : 0; 
+         }
+         
+         if (awtWMStaticGravity == 1) {
+             return true;
+         }
+         
          switch(getWMID()) {
            case XWM.ICE_WM:
                /*
                 * See bug #228981 at IceWM's SourceForge pages.
                 * Latest stable version 1.0.8-6 still has this problem.



*** /export/bino/t1/webrev/src/solaris/native/sun/xawt/XToolkit.c-      Tue Oct 21 14:38:04 2003
--- XToolkit.c  Tue Oct 21 14:31:01 2003
--------------------------------------------------------------------------------
*** 954,958 ****
--- 954,981 ----
      } else {
          isComponent = JNI_FALSE;
      }
      return isComponent;
  }
+ 
+ /*
+  * Class:     sun_awt_X11_XToolkit
+  * Method:    getEnv
+  * Signature: (Ljava/lang/String;)Ljava/lang/String;
+  */
+ JNIEXPORT jstring JNICALL Java_sun_awt_X11_XToolkit_getEnv
+ (JNIEnv *env , jclass clazz, jstring key) {
+     char *ptr = NULL;
+     const char *keystr = NULL;
+     jstring ret = NULL;
+     
+     keystr = (*env)->GetStringUTFChars (env, key, 0);
+     if (key) {
+         ptr = getenv(keystr);
+         if (ptr) {
+             ret = (*env)->NewStringUTF(env, ptr);
+         }
+         (*env)->ReleaseStringUTFChars (env, key, (const char*)keystr);
+     }
+     return ret;
+ }
+ 


*** /export/bino/t1/webrev/make/sun/xawt/mapfile-vers-  Tue Oct 21 14:38:04 2003
--- mapfile-vers        Tue Oct 21 14:34:00 2003
--------------------------------------------------------------------------------
*** 247,256 ****
--- 247,257 ----
          Java_sun_awt_X11_XInputMethod_adjustStatusWindow;
          Java_sun_awt_X11_XlibWrapper_XQueryPointer;
          Java_sun_awt_X11_XlibWrapper_XFreeCursor;
          Java_sun_awt_X11_XToolkit_getDefaultXColormap;
          Java_sun_awt_X11_XToolkit_getDefaultScreenData;
+         Java_sun_awt_X11_XToolkit_getEnv;
          Java_sun_awt_X11_XlibWrapper_XCreateBitmapFromData;
          Java_sun_awt_X11_XlibWrapper_XFreePixmap;
          Java_sun_awt_X11_XlibWrapper_XAllocColor;
          Java_sun_awt_X11_XlibWrapper_XCreatePixmapCursor;
          Java_sun_awt_X11_XlibWrapper_XQueryBestCursor;



###@###.### 2003-10-21
                                     
2003-10-21
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b28


                                     
2004-06-14



Hardware and Software, Engineered to Work Together