On Fri, May 07, 1999 at 12:32:04AM -0400, Bob Woodside wrote:
> Dominik Vogt wrote:
> >
> > > 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?
> >
> > I have just patched the current delevopment sources. This will be in the
> > next version.
>
> That's odd, because I couldn't reproduce the problem, using last
> night's CVS.
I could reproduce it with SloppyFocus.
> 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.
In any case, a transient being closed should transfer the focus back
to its 'parent'.
> 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.
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.
> 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.
Well, try it and see if it bothers you. If it does we can make another
style option.
> 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.
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.
> 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.
Yup.
Bye
Dominik ^_^
--
Dominik Vogt, dominik.vogt_at_gmx.de
Reply-To: dominik.vogt_at_gmx.de
--
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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Fri May 07 1999 - 05:26:17 BST