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




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) 
======================================================================

N/A

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

See also 4457472.  Commit to fix in Tiger.  
 xxxxx@xxxxx  2001-05-18

Reproducible on build 1.4.0-beta_refresh-b70.
 xxxxx@xxxxx  2001-07-11



 xxxxx@xxxxx   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.

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



 xxxxx@xxxxx   2002-08-06

A reply from Dominik Vogt < xxxxx@xxxxx >:

| 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 (fvwm- xxxxx@xxxxx ).

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

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.  
 xxxxx@xxxxx  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.

 xxxxx@xxxxx  2003-09-29

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

 xxxxx@xxxxx  2003-10-21

yes I see this as well. RUnning fvwm 2.2.4 and Solaris 8 with
Java 1.3.1

Isn't this a duplicate of the longstanding bug 4102292?

        I can't quite agree with this latest assessment. I think
that rmyorston's comment from SEP 26, 2001 was correct: it looks
to me like a restatement of bug # 4102292, which has been out-
standing for about 4.5 years.

        I'm one of FVWM developers, and I'd like to get a joint
effort going between Sun and the FVWM team to get this resolved
once and for all. If one of the Sun developers would contact us
we can initiate a discussion of how to proced. You can either
contact me directly at dumbledore@woodsway.com, or open it up to
discussion on the FVWM developers' mailing list at
fvwm-workers@fvwm.org.

Regards,
Bob Woodside

With fvwm 2.5.7

With Java 1.3.1 this "bug" is unreproductible.

This bug is present with Java 1.4.1.
An FVWM workaround:

Style "match_your_java_apps" \
       FixedPPosition, UsePPosition, UseTransientPPosition

Regards, Olivier