Subject: Re: [Fwd: Question about 4401846]

From: Dan Espen <[email-masked]>
Date: Mon, 05 Aug 2002 17:26:14 -0400

"Valeriy E. Ushakov" <[email-masked]> writes:
> Hi, Dan.
> 
> 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.

Hi,

  To reach the developers supporting Fvwm, you need to
use the email address [email-masked].  I'm forwarding
this.

> Thanks.
> 
> 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:
> 
> > On Fri, Aug 02, 2002 at 03:59:34PM -0700, Gordon Prieur wrote:
> > 
> > > > However, I have no objection to your forwarding it: the 
> > > > Evaluation section of the bug report is intended to be 
> > > > publically available.  BTW, I'd love it if fvwm developers 
> > > > could add an option to handle the window gravity issue. 
> > > 
> > > They claim they already do. Thats why I got involved. It looked like
> > > the clasical case of 2 groups saying the problem is the other groups.
> > > I hope to get them talking to your group, but first I wanted to give
> > > them the updated evaluation.
> > 
> > <uwe@swallow:~> (2029) fvwm-config --version
> > 2.4.8
> > <uwe@swallow:~> (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).
> > 
> > -uwe
> 
> -uwe

-- 
Dan Espen                           E-mail: [email-masked]
444 Hoes Lane  Room RRC 1C-214      Phone: (732) 699-5570
Piscataway, NJ 08854
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 6 Aug 2002 01:50:54 +0200

> > problem with interpretation of gravity in configure requests.  See my

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 ([email-masked]).

> > On Mon, Aug 05, 2002 at 08:31:29PM +0400, Valeriy E. Ushakov wrote:
[snip]
> > > called on XtAddAppTimeOut).

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 6 Aug 2002 01:59:15 +0200

Could someone please forward my previous message to the JavaSoft
person?  My mail provider's name server cannot resolve the domain
name of his address.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Mon, 05 Aug 2002 20:40:30 -0400

> person?  My mail provider's name server cannot resolve the domain

Done.