[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: Re: address@hidden: mouse-autoselect-window needs a

From: David Kastrup
Subject: Re: address@hidden: Re: address@hidden: mouse-autoselect-window needs a de lay]]
Date: Sun, 03 Sep 2006 18:02:05 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Richard Stallman <address@hidden> writes:

> Would people please comment on this bug fix?
> From: martin rudalics <address@hidden>
> Subject: Re: address@hidden: mouse-autoselect-window needs a  de
>  lay]

I think a delay is the wrong thing to do here since it makes stuff
unpredictable.  The right fix, in my opinion, would be lazy focus
change: only when a keyboard or mouse event occurs in the new window,
is the focus changed.  That has the disadvantage that the user may be
surprised by the change since the old window appears to have focus
before typing a key.

In order to mitigate the surprise, it might be reasonable to visibly
unfocus the old window (by the different highlighting of the mode line
and the different cursor type), but not refocus a different window
before an event occurs.

A more radical approach would be to move toolbar and menubar just
above the currently selected window.  This would also require less
mouse movement, but would likely earn us an award for the most weird
user interface look ever.

I don't think it is reasonable to expect to sort this out before the
release.  I think that there are several viable possibilities, and
we'd need the feedback of testers trying each of those out for several
weeks before it would be viable to decide on a sensible strategy.

I don't think that the delay stuff is a good strategy: it brakes and
confuses the user when he indeed wants to change focus, and it causes
hectic when he doesn't.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]