Subject: transients for ClickToFocus & StaysOnTop

From: [email-masked]
Date: Sun, 13 Dec 1998 19:19:51 -0600 (CST)

Full_Name: Michael Han
Version: 2.1.5
CVS_Date: 1600 GMT 12/13/1998
OS: Linux 2.0.34 + RedHat 4.1
X_Server: AcceleratedX 2.1
Submission from: (NULL) (206.86.216.254)

This is an old bug that I remember from 2.0.4?. Transients for
StaysOnTop & ClickToFocus windows are obscured by their parents being
raised above them, if the event that maps the window is the first
event to map a window in the StaysOnTop window, which was entered
without focus.

That is, with ClickToFocusDoesntPassClick, a first click focusses the
StaysOnTop window. An event then maps a transient, which becomes
obscured by its parent. Subsequent transients correctly remain above
the parent until the focus exits the StaysOnTop window (or possibly
something else? RAISED flags get twiddled? stack order gets changed?).
And for ClickToFocusPassesClick, the first event in the window that
maps a transient will see the parent raised above its transient. Focus
need never pass to the StaysOnTop window, as in the case of a
StaysOnTop FvwmPager with Balloons.

This occurs irrespective of
ClickToFocusRaises/ClickToFocusDoesntRaise. It is not a problem with
other focus policies (MouseFocus, SloppyFocus). To reproduce this,
set:
GlobalOpts ClickToFocusPassesClick
Style "Foo" ClickToFocus, StaysOnTop

Then create some window with the title Foo, and that can create menus
or other transients with a single event, such as a click or an entry
into a child. Give focus to some other window. Then return to the
window and do something that maps a transient. The transient should
quickly map on top of the parent, and then have the parent raised
above it. Subsequent events mapping transients should do the right
thing. I'm fairly certain others confirmed this bug on other OSes and
installations when I first brought it up many moons ago.

MouseFocus and SloppyFocus apparently do something upon entry into a
window (aside from giving focus) that ClickToFocus entry doesn't do.
Or that's the way it looks to me, based on a limited understanding of
the code and of X. It's interesting the focus isn't really the
apparent cause (it works with FvwmPager Balloons, where you never have
to have a focus change to reproduce this behavior), though the
settings for focus policy control its presence.

I have a funny feeling that this happens because in ClickToFocus,
transients are given focus with a SetFocus(), when you have a
HandleMapNotify() and similar circumstances.

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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].