RFE: Never, ever steal focus.

Owen Taylor otaylor at redhat.com
Wed Jan 6 21:08:43 UTC 2010


On Wed, 2010-01-06 at 12:35 -0600, Serge E. Hallyn wrote:
> Quoting Adam Jackson (ajax at redhat.com):
> > On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
> > > Quoting Adam Jackson (ajax at redhat.com):

> > > 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.
> 
> Yes, exactly.  You're saying that
> 	1. there are cases where you want a window to pop up
> 	2. it's too complicated to figure out which windows should pop up
> 	3. so windows should always pop up, no point being configurable
> 
> and ridiculing us over (2).  I'm saying there are no cases where I want
> a popup, so we can easily have 2 configurable options: always have windows
> pop up and take focus, never have them do so.
> 
> That's all.

This discussion would make a whole lot more sense if the current
behavior was actually that windows always pop up and steal focus.

It isn't.

We actually have a mechanism that works pretty well for knowing when
focus should be stolen and when not. (Not a Fedora or GNOME method, but
one encoded in the freedesktop.org standards.)

In simple terms, it works by comparing timestamps:

 - What was the timestamp of the user action that triggered the
   window to pop up?

 - What was the timestamp of the last user action with the currently
   focused window?

If the timestamp for the user action that triggered the popup is newer
than the timestamp of the last user action with the currently focused
window, then focus is transferred.

This isn't 100% perfect ... it's no substitute for electrodes implanted
in the user's brain. 

But it's a pretty darn good method when all the actors are playing by
the rules. So, when things go wrong, our first step shouldn't be adding
a configuration variable, but trying to figure out if there is a bug
that needs to be fixed.

- Owen





More information about the fedora-devel-list mailing list