Subject: 2.3.4: Application Menus Off Position

From: Amir Chossrow Akhavan <[email-masked]>
Date: Thu, 10 Jun 1999 01:14:28 -0700 (PDT)

Hi!

Under the latest CVS (June 9th), in a number of programs, 
menus (application menus, NOT fvwm menus) display an
annoying behaviour.

As an example, netscape:

1. fire up netscape
2. move the window to some arbitrary position.
4. Click on a menu button.

Effect: the menu will appear at a position that corresponds the initial 
        position, as if the window hadn't been moved.

I provide a list of some programs that show the effect and some programs 
that don't, because the bug might be depending on the X toolkit the apps
use.
Sorry, I didn't have the time yet to check the CVS for June 4th - June
8th, but I know for sure this bug wasn't present before June 4th.

broken:
 Acroread
 addressbook (tcl/tk ?)
 Amaya (html-editor)
 control-panel tools
 exmh (mailer)
 FileRunner (tcl/tk)
 ghostview
 ical (calendar)
 impress (tcl/tk)
 jazz (MIDI sequencer)
 Nedit
 Netscape (4.51 / 3.04)
 rosegarden (MIDI editor)
 SoundStudio (tcl/tk?)
 slab (StudioLab, hard disk recorder, tcl/tk)
 xfig
 X-files
 xconfig (tcl/tk)
 XPaint
 xwave

ok:
 (probably) All Gnome Applications
 (probably) All KDE/Qt Applications
 Applixware
 Eterm (after using CTRL + mouseclick ;)  )
 emacs (of course)
 GIMP (well, GTK)
 licq (qt toolkit?)
 mtv
 StarOffice (does its own thing anyway ;) )
 tgif
 XMan
 xmovie
 xpdf

System settings:
RH Linux 5.2, Kernel 2.2.9
X Server: XFree86 3.3.3.1-1
gnome 1.0
libc 2.0
make-3.76.1-2
automake-1.4-1
Color Depth: 24/32 bit

thanx and happy hacking,
Amir

--
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: Thu, 10 Jun 1999 12:19:48 -0600

> 8th, but I know for sure this bug wasn't present before June 4th.

I can confirm this on my system. Since the only broken application I use
is Netscape I didn't get suspicios. I thought Netscape was freaking out
again (as usual). The bug has been around for about a week now. There
are two possible candidates that may (or may not) have caused it:

 - the strokes patch (?)
 - A patch to events.c by Matthias (I don't understand it myself.
   Matthias, what d you say?)

        * fvwm/events.c (HandleConfigureRequest): send the synthetic
        ConfigureNotify here whenever the client may not receive a real
        ConfigureNotify on its toplevel window (as the ICCCM demands).
        As a hack to support buggy tk, duplicate the ConfigureNotify on
        the frame window.

Any ideas? Has window placement changed recently?

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [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: Tim Phipps <[email-masked]>
Date: Thu, 10 Jun 1999 14:32:23 +0100

> Any ideas? Has window placement changed recently?

This might also explain the problems with tranparent Eterms (I think
they might not be getting a ConfigureNotify when they are mapped).

Cheers,
Tim.

---

From: Bob Woodside <[email-masked]>
Date: Thu, 10 Jun 1999 13:28:34 -0400

Dominik Vogt wrote:
> 
>                   The bug has been around for about a week now. There
> are two possible candidates...
> 

	This is the culprit. I just reinstated the code in borders.c
(SetupFrame) and the problem went away. I thought I'd wait and see if
Matthias has any further comments or insights on this before committing
the change.

- Bob

---

From: Matthias Clasen <[email-masked]>
Date: Fri, 11 Jun 1999 17:21:37 +0200

> Matthias has any further comments or insights on this before committing

So does this mean that applications really expect to see ConfigureNotifys
even if they haven't sent a ConfigureRequest ? This is incredibly broken,
if you ask me. If they need to track their absolute position (to pop up
override-redirect menus, eg), they should query their geometry and use
TranslateCoordinates...

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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: Tim Phipps <[email-masked]>
Date: Fri, 11 Jun 1999 16:51:56 +0100

> override-redirect menus, eg), they should query their geometry and use

If you run without a window manager and move a window the client gets a
configure notify event from the server.  With window managers the
windows are reparented into the border and they never move (relative to
their parent) so the server never sends configure notify's.  That's why
the window manager has to send these synthetic ones. Polling their
geometry every time a menu is popped up is not the way to go.

Cheers,
Tim.

PS clients don't send configure requests either, they do an
XMoveWindow() and the server translates this into a configure request
because the window manager has set a subspace-redirect attrubute
somewhere. The window manager does some computing and moves the parent
window of the client.
--
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: Matthias Clasen <[email-masked]>
Date: Fri, 11 Jun 1999 17:58:26 +0200

> geometry every time a menu is popped up is not the way to go.

But if you run without a window manager, windows will normally not be moved
unless they send the ConfigureRequest all by themself...

---

From: Tim Phipps <[email-masked]>
Date: Fri, 11 Jun 1999 17:12:27 +0100

> unless they send the ConfigureRequest all by themself...

Clients move themselves with XMoveWindow(), well maybe that's unusual
but lots of them resize themselves and the mechanism is the same. With a
window manager running the client isn't guaranteed to get what it wants
so it can't pop up menus where it think they should be, it can use the
configure notifys to track where it is and then it doesn't matter wetehr
a window manager is running or not or wether the clients moved the
window or something else did.

Cheers,
Tim.

---

From: Matthias Clasen <[email-masked]>
Date: Fri, 11 Jun 1999 18:18:07 +0200

> window or something else did.

OK, right. We should send ConfigureNotifys then. But I still think that
the stuff with the sendEvent parameter of SetupFrame is messy. Its only use
is to force sending a ConfigureNotify even if no resizing or moving happened.
The only case where this might be necessary should be in response to a 
ConfigureRequest, where it is handled independently now. 

Matthias

---

From: Tim Phipps <[email-masked]>
Date: Fri, 11 Jun 1999 17:35:54 +0100

> ConfigureRequest, where it is handled independently now.

I think there is one case missing: when a client creates it's window the
first time it won't get put where the client created it because the
window manager will have moved it to make room for the decorations. A
configure request won't go to fvwm because it got a subststructure
notify instead.  In add_window.c there is a call to SetupFrame() with
the send event flags set to true.  I think sending a configure notify at
this point would fix this bug and Eterms transparency problems.

Actually there are lots of places that SetupFrame is called with send
event forced.  May be some of them are uneccessary but removing the send
events from SetupFrame may cause bugs that we haven't tested noticed
yet.

Cheers,
Tim.