Subject: FVWM: more on focus behavior

From: "Philip H. Jensen" <[email-masked]>
Date: Thu, 6 May 1999 18:18:12 -0400 (EDT)

Okay, folks.. this may well be a Netscape bug, but I thought I'd ask.

Linux (RH5.1 at the moment), fvwm2 1.46 I think, NS 4.005.
ClickToFocus.

The WindowList shows, say Xterms as window 1 and 3, Netscape as window 2.
Focus on Netscape.  Alt/L - goto URL dialog comes up - type type type,
Enter - dialog goes away AND FOCUS RETURNS TO WINDOW 1, NOT TO NETSCAPE.
Maddening.  Any solution?

  thanks,
  Phil

--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 7 May 1999 02:09:26 +0200

> Linux (RH5.1 at the moment), fvwm2 1.46 I think, NS 4.005.
                               ^^^^^^^^^^
Is this 2.0.46, 2.1.4 or 2.1.6?

> Enter - dialog goes away AND FOCUS RETURNS TO WINDOW 1, NOT TO NETSCAPE.

I have just patched the current delevopment sources. This will be in the
next version.

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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Philip H. Jensen" <[email-masked]>
Date: Fri, 7 May 1999 00:09:24 -0400 (EDT)

On Fri, 7 May 1999, Dominik Vogt wrote:

> ...

> Is this 2.0.46, 2.1.4 or 2.1.6?

Sorry, yes of course 2.0.46, don't know why I was too lazy to check...

> > [description of problem where Netscape fails to reclaim focus after
> > a dialog window etc. is dismissed]

> I have just patched the current delevopment sources. This will be in the

Bless you, Sir!

---

From: Bob Woodside <[email-masked]>
Date: Fri, 07 May 1999 00:32:04 -0400

> I have just patched the current delevopment sources. This will be in the

	That's odd, because I couldn't reproduce the problem, using last
night's CVS.

	I concluded that this had to be caused by one of two things. Either
there's a mix of ClickToFocus and MouseFocus windows (the mouse cursor
is resting atop a MouseyFocus window when the transient disappears), or
Phil clicked on the xterm-1 window while the transient NS dialogue was
up, altering the order of the last-focused chain.

	Phil -- is either of these the case in your situation?

	Dominik -- I see what you did to change this behavior. I'm not sure I'm
100% convinced that it's always what is wanted in case number 2. I can
easily picture a case where it is not.

	Say I have a window like the one I'm typing this message in at the
moment, which covers most of Netscape's browser window. Suppose that the
message I'm replying to contains a couple of URL's that I want to check.
I click File->Open Page in the browser window. I don't force windows to
raise on the focus click, so the window I'm typing in isn't obscured.
The transient dialogue appears, I select the URL and paste it into the
dialogue, and hit enter. I'd really rather have focus return to the
window I was typing in while NS loads that graphics-laden,
singing-dancing page over a slow link.

	It's sort of a damned if you do, damned if you don't situation, because
we can't really know for sure just which window a user considers the
most important at the moment - particularly if he has oddball habits
like mine.

	For the mouse-focus case, I suppose this is the more intuitive way to
behave - I only use Mouse/SloppyFocus occasionally, so I'm not a good
judge.

	I guess we'll just have to see over the next few days whether anyone
finds this a significant annoyance, in which case it should probably be
made optional.

- Bob

---

From: Tim Phipps <[email-masked]>
Date: Fri, 07 May 1999 09:57:23 +0100

> Maddening.  Any solution?

Upgrade fvwm to version 2.2.  It's a feature of fvwm before 2.2 that the
internal window list order depends on the order of creation of windows. 
After 2.2 to list is kept in most recently focussed order so that
closing windows does the right.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 7 May 1999 12:25:05 +0200

> 	That's odd, because I couldn't reproduce the problem, using last

I could reproduce it with SloppyFocus.

> up, altering the order of the last-focused chain.

In any case, a transient being closed should transfer the focus back
to its 'parent'.

> easily picture a case where it is not.

I *am* sure I'm not 100% convinced :-) It won't work if the focus transfers
from one transient to another of the same application. Perhaps we should
check not only if the last focused window is the transientfor window but
also if the last focused window has the same transientfor window.

> most important at the moment - particularly if he has oddball habits

Well, try it and see if it bothers you. If it does we can make another
style option.

> behave - I only use Mouse/SloppyFocus occasionally, so I'm not a good

Whit mouse/sloppy focus this can't happen. If the pointer is over some
different window than the transient with the focus this must be because
the focus was grabbed by the transient. This can only happen with the
focus on its 'parent' (at least with yesterday's patch). In this case
the user will most likely expect to get the focus back where it was.

> finds this a significant annoyance, in which case it should probably be

Yup.

Bye

Dominik ^_^

---

From: Bob Woodside <[email-masked]>
Date: Fri, 07 May 1999 07:44:36 -0400

> closing windows does the right.

	Hmm...my recollection is that this change was to get rid of the
discrepancy between ClickToFocus and MouseFocus handling. I believe that
the list order was changed for ClickToFocus windows, but got into a
horrible muddle if you had a combination of click focus and mouse focus
windows. I don't recall having this problem under 2.0.4x.

- Bob

---

From: Bob Woodside <[email-masked]>
Date: Fri, 07 May 1999 07:44:45 -0400

> Well, try it and see if it bothers you. If it does we can make another

	Gee, it's nice to be able to say that at last!  :-)

- Bob

---

From: Tim Phipps <[email-masked]>
Date: Fri, 07 May 1999 12:52:36 +0100

> In any case, a transient being closed should transfer the focus back

Only if you want it to. Could we make this a style option?

> the user will most likely expect to get the focus back where it was.

In mousefocus mode you can still change focus without using the mouse. 
I use the Direction function to do this and you don't have to warp the
mouse. So it is possible to have the mouse over one window with the
focus on another (possibly transient) window.  In this case closing the
focus window should switch back to the mouse-containing window
(probably).

Cheers,
Tim.

---

From: [email-masked]
Date: 08 May 1999 23:27:11 +0200

Dominik Vogt <[email-masked]> writes:

  > In any case, a transient being closed should transfer the focus
  > back to its 'parent'.

Really?  Consider the informational `download status' windows of
Netscape.  I'd be rather surprised if the finishing of a download
moved focus away from whatever I was using at that time.

But maybe these `download status' windows aren't transient.

But if they are, I'm really unsure what should be done about it.
OT1H, after hitting the OK button in an `enter search string' Netscape
window, I surely want focus to return to the parent.  OTOH, there's
this `download status' thing.  And then, there are the authentication
popups from Netscape -- I find that I sometimes tell Netscape to go to
a URL and go back to my mail reader.  After some time, an
authentication window pops up.  I enter the data, hit RET, and
continue to read mail for a while, since I know that the page will
take some time to be downloaded completely.

Hm.

Maybe it is safest to return focus to the window that had focus before
the transient appeared.

Whatcha think?

kai
-- 
Abort this operation?   [Abort]  [Cancel]

---

From: Adam L Rice <[email-masked]>
Date: Sun, 9 May 1999 00:26:56 +0100

> But maybe these `download status' windows aren't transient.

AFAIK, they aren't. Try the following simple experiment: start a download,
then close all other windows. The download continues until the end, then the
program exits. I don't think it would do that if the download window was a
transient.

> Whatcha think?

In my opinion, on the closure of a transient, if fvwm can't deduce the new
focus from the mouse position[1], it should move to the parent of the
transient. This will occasionally do "the wrong thing" for people with
click-to-focus on and auto-raise off, but it serves them right for mixing
their metaphors.

[1] ie. ClickToFocus is on, or SloppyFocus is on and the mouse pointer is
over the root window.

-- 
Adam Rice -- [email-masked] -- Blackburn, Lancashire, England

---

From: Michael Tiefenback <[email-masked]>
Date: Sat, 8 May 1999 21:03:19 -0400 (EDT)

> [1] ie. ClickToFocus is on, or SloppyFocus is on and the mouse pointer is

I've not been following this dialogue carefully, and I think I have heard
the answer I would give to this issue.  But I'll say it explicitly in case
I am wrong:

The focus change should only happen if the "transient"  window is the one
which already _has_ the focus.  If it doesn't then no refocus should
occur.  None of the issues I have noticed being discussed would be
answered wrongly with this. 

Michael Tiefenback

---

From: [email-masked]
Date: 09 May 1999 12:42:12 +0200

Michael Tiefenback <[email-masked]> writes:

  > The focus change should only happen if the "transient" window is
  > the one which already _has_ the focus.

Eek.  I missed that one.  Thanks for clearing this up.  Thus, my
posting is bogus.

kai