On Mon, Aug 05, 2002 at 05:26:14PM -0400, Dan Espen wrote:
> "Valeriy E. Ushakov" <[EMAIL PROTECTED]> writes:
> > I'm a JavaSoft contractor for AWT group. There are several bugs filed
> > against jdk running under fvwm2. Several of them are caused by a
> > problem with interpretation of gravity in configure requests. See my
> > mail below.
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-workers@fvwm.org).
> > PS: I hope that weird awt top-level insets problems under fvwm2 went
> > away with JDK1.4.
> >
> > On Mon, Aug 05, 2002 at 08:31:29PM +0400, Valeriy E. Ushakov wrote:
[snip]
> > > <[EMAIL PROTECTED]:~> (2029) fvwm-config --version
> > > 2.4.8
> > > <[EMAIL PROTECTED]:~> (2030) wish
> > > % wm geometry . # window at +0+0
> > > 200x200+0+0
> > > % wm geometry . +1+1 # window decor is moved off-screen
> > > # i.e. client is at +1+1, not decor
> > >
> > > Other window managers that have this problem are IceWM and
> > > Enlightenment.
> > >
> > > Running these same wish commands under, e.g., olwm places the window
> > > correctly.
> > >
> > > I'm not sure what's the problem might be, but enabling debug messages
> > > in fvwm and adding few more in HandleConfigureRequest I can see e.g.
> > > java requesting a window positioned at (3,11):
> > >
> > > TL: reshape(0x24d058/0x2c00041,
> > > TL: x = 3, y = 11, w = 153, h = 195, setXY)
> > >
> > > and fwvm doing:
> > >
> > > [UWE] ConfigureRequest: x=3 y=11
> > > [FVWM][SetupFrame]: <<DEBUG>> Routine Entered (x == -4, y == -18, w ==
> > > 153,
> > > h == 195)
> > >
> > > I.e. x and y are off by decoration size (left=7, top=29).
> > >
> > >
> > > A simple Xt test case that does this when window is already mapped:
> > >
> > > XtVaSetValues(toplevel, XtNx, 5, XtNy, 5, NULL);
> > >
> > > has the same problem too (the above code was just added to xlogo to be
> > > called on XtAddAppTimeOut).
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
