On Wed, 2010-01-06 at 22:43 -0500, Gregory Maxwell wrote:
> On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson <ajax@xxxxxxxxxx> wrote:
> > On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> >> There is no case where I want a new window or popup to take focus. Makes
> >> for an easy algorithm. (hitting r in mutt is not a problem :)
> >
> > There is no case where _you_ want this, sure.
>
> Some people what that.
> Many other people want the focus change to happen in a _few_ limited
> cases where it makes sense.
>
> Current behaviour fails to accurately predict those cases (no doubt
> because, in part, the limited acceptable cases differ from person to
> person), and so you get unexpected focus theft. This is bad for
> everyone.
The problem is that the "automatic focus change only when intended by
user" will never be done 100% correctly. This is just impossible to do.
So the actual better user experience case would be to always require the
user to press some (easy) key combination to transfer the focus from the
currently focused window. The user would quickly learn it.
Then the problem shifts to whether the newly created windows should be
opened in the background or not. It would be also easy to teach the
user. I can for example imagine that the new window would first appear
on the top overlayed with a semi-transparent text like:
"Press Ctrl-Tab to send the window to background, press Alt-Tab to start
typing into the window, press Esc to close the window"
The other keypresses would still go to the previously focused window.
With the compositing WMs it would be also easily possible to make the
new window semitransparent over the old window so the user would still
see that he is typing into the old window.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
