>
>
> >>>>> Barry Warsaw writes:
>
> Barry> Fvwm has nothing to do with it. If, when the Open Location
> Barry> dialog was popped up, Netscape redirected its application's
> Barry> focus to that window, the problem would be solved. It *can*
> Barry> be done with pointer-focus policy, no pointer warping, no
> Barry> server grabs, and no need to pop the window up under the
> Barry> cursor. Your application, or toolkit, just has to provide
> Barry> the right kind of focus management policy. Maybe that's
> Barry> hard, but that's an engineering problem, not made impossible
> Barry> by the design of pointer-focus policy.
>
> >>>>> Scott Raney writes:
>
> Scott> I think this is wrong, at least as I understand pointer
> Scott> focus. Maybe you're thinking of sloppy focus or something.
> Scott> Pointer focus is where the window with the mouse cursor in it
> Scott> has the keyboard focus. There are no exceptions to this
> Scott> rule, and warping the cursor is the only way an application
> Scott> can ensure that one of its windows gets the focus.
>
> Come on now! Look at these claims side by side:
>
> (1) Using PointerFocus, the *only* way for a window to get focus is if
> the mouse pointer is in the window.
>
> (2) Using ClickToFocus, the *only* way for a window to get focus is if
> the user clicks on it.
>
> Now, it is very clear that no program I know of obeys rule (2), so why
> should any program obey rule (1)? IMHO, the two rules above exactly
> correspond to each other.
This is a good point. The reason why 2) isn't an accurate description
is because the most common way a for a dialog window to get the focus
in an explicit focus environment is for the window manager to give it
the focus automatically (or to tell it to take the focus) when the
window opens. In pointer-focus mode, they doesn't do this.
> I propose that we invent DumbPointerFocus and DumbClickToFocus which
> obey rules (1) and (2), respectively, and that we reserve PointerFocus
> and ClickToFocus for the obvious improvements on the two rules above.
>
> So far, Scott has been comparing ClickToFocus with DumbPointerFocus,
> which just isn't fair.
It it fair, but only because in ClickToFocus environments the wm is an
active participant in the focus management process, whereas in
pointer-focus environments it is passive and the
*application-developer* is responsible for figuring out where the
focus should go each time a window opens. Since currently very few
developers do this (and I would guess you'll be in for a long wait if
you're expecting them to change), what you need is a "clever"
pointer-focus mode in which the window manager assigns focus to
dialogs when they open. The transient-for prop would be one good cue
for the wm to use, with the MwmHints input_mode field being another
(e.g., if the dialog is modal, you *always* want the focus to go to
that window).
> Please feel free to correct me if you disagree,
I guess I don't, except that I think "DumbPointerFocus" mode is a not
a good label for behavior you describe in 1) above. The fact that
most applications work this way in a pointer focus environment is the
result of the design of those applications and is not determined by
WM settings (which is what is generally meant by wm "modes").
Regards,
Scott
> kai
> --
> Life is hard and then you die.
>
--
***************************************************************
Scott Raney raney_at_metacard.com http://www.metacard.com
Tcl and ksh: syntactic gymnastics
MetaCard: it does what you think
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Sun Oct 27 1996 - 14:59:28 GMT