[comp.windows.x] ConfigureWindow bug in R4 twm

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/12/90)

    Unfortunately we have to release a product soon that relies on a
    conformant window manager, so I will probably have to try fixing
    it myself.

The ICCCM does not require a window manager to put windows where you
ask them to be put.  If you have a product that demands this from a
window manager, you deserve whatever problems you encounter.  [This
doesn't mean twm isn't buggy, of course.]

jdi@Franz.COM (John Irwin) (01/12/90)

Here is a bug report I sent to xbugs.  I thought I'd post it here also so
noone else has to figure out why the heck windows aren't where they're
supposed to be.

I was told that this is a known bug and will be fixed eventually.
Unfortunately we have to release a product soon that relies on a
conformant window manager, so I will probably have to try fixing
it myself.  If anyone else is working on this, I'd appreciate a note.
Thanks.

	-- John Irwin

--
			  X Window System Bug Report
			    xbugs@expo.lcs.mit.edu


VERSION:
    R4

CLIENT MACHINE and OPERATING SYSTEM:
    Sun 4/260 OS4.0.3, but it's not important

DISPLAY TYPE:
    Sun BW2, but it's not important

WINDOW MANAGER:
    twm

AREA:
    twm

SYNOPSIS:
    Twm's handling of ConfigureWindow requests is both incorrect and
    not ICCCM compliant.

DESCRIPTION:
    I create a window at 1000,1000 that has a win_gravity hint of Center.
    The window has a width and height of 100 and a border width of 0.
    I then map the window.  Twm correctly places the top left corner of
    MY window (hereafter called mywindow) at 1000,1000, which it does by
    locating the frame window to account for the frame's title and border.
    (I use three pixel twm borders, but that shouldn't matter)
    All is fine at this point.

    Now I issue a ConfigureWindow request asking for the window to be moved
    to 1005, 1010.  (I also ask for a border-width of 0 as section 4.1.5
    of the ICCCM specifies)

    Section 4.1.5 of the ICCCM says this about configuring the window:
	"Client configure requests areinterpreted by the window manager
	 in the same manner as the initial window geometry mapped from
	 Withdrawn state, as described in Section 4.1.2.3.)"

    Since my win_gravity hint is still Center, I would expect mywindow to be
    moved to 1005, 1010.  (Accordingly the frame would be at 1002, 1007,
    assuming the window has no title)  This is not what happens.

    Instead, twm moves mywindow to 1008, 1013.  IE: twm moves the *FRAME* to
    1005, 1010.  Now, you could argue that this is still ICCCM compliant, since
    the client isn't guaranteed to get what he wants.  But it does violate the
    above quoted paragraph.

    Also, twm sends a synthetic ConfigureNotify event to the client describing
    the new state of mywindow, as it should.  But it lies about where mywindow
    is.  The event says that mywindow is now at 1005, 1010.  Surely section
    4.1.5 specifies that the ConfigureNotify the client receives applies to
    the client window and not the frame window?

REPEAT BY:
    Described above.

SAMPLE FIX:
    I've looked at the code a while, but it's pretty messy.  Specifically
    AddWindow and HandleConfigureRequest do not share any code, and indeed do
    not look much alike, as they should since they both do (what's supposed
    to be the same) placement.

jdi@sparky.Franz.COM (John Irwin) (01/16/90)

In article <9001112222.AA06723@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:
>
>    Unfortunately we have to release a product soon that relies on a
>    conformant window manager, so I will probably have to try fixing
>    it myself.
>
>The ICCCM does not require a window manager to put windows where you
>ask them to be put.  If you have a product that demands this from a
>window manager, you deserve whatever problems you encounter.  [This
>doesn't mean twm isn't buggy, of course.]

The problem isn't that twm puts windows in the wrong place; the fact that
it does so is, by itself, not cause for labelling twm non-compliant.
(Although my reading of section 4.1.5 suggests that the current behaviour
 is "not very compliant.")

The problem is that twm tells the client that it put the window in the
*right* place.  An excerpt from my bug report:

    ...
    Instead, twm moves mywindow to 1008, 1013.  IE: twm moves the *FRAME* to
    1005, 1010.  Now, you could argue that this is still ICCCM compliant, since
    the client isn't guaranteed to get what he wants.  But it does violate the
    above quoted paragraph.

    Also, twm sends a synthetic ConfigureNotify event to the client describing
    the new state of mywindow, as it should.  But it lies about where mywindow
    is.  The event says that mywindow is now at 1005, 1010.  Surely section
    4.1.5 specifies that the ConfigureNotify the client receives applies to
    the client window and not the frame window?
    ...

IE: it would be ok (but not optimal) if twm put the window in the wrong place
and then told me that was where it put it.  Instead twm says it put the window
one place while actually putting it somewhere else, which messes up my client's
cached window state.

	-- John Irwin
	   Franz Inc.