[Usability] Re: Error dialogs (among others?) and focus stealing prevention

I don't think it's a good idea to try to prevent an application from stealing focus from itself. Apps should resolve any such usability problems by themselves.

In particular, a new modal child window, such as most error dialogs, should always get focus. It simply doesn't make sense that it wouldn't.


Elijah Newren wrote:
On Tue, 26 Oct 2004 23:59:18 -0400, Havoc Pennington <hp redhat com> wrote:

On Tue, 2004-10-26 at 21:48 -0600, Elijah Newren wrote:

 If the error dialog is from the same application, it will
often steal focus (but not always--depends on when keystrokes are
processed relative to the gtk_widget_show() and the window manager
mapping...blah blah blah.  Yes, Bryan, I wrote a test application to
verify this).  The fix is relatively simple--have the application call
"gtk_window_set_focus_on_map (error_dialog, FALSE);" before showing
the error dialog.

I don't understand this fully; if the dialog is opened in response to a
key event, it would have the timestamp of said event and get focus. But
if it's opened out of the blue (say in a timeout, or due to network
communications), the timestamp should be 0, right?

Short answer: Should be, but who's responsible to make it be so?

Long answer:
Okay, so the spec states that it is the application's responsibility
to provide a hint (_NET_WM_USER_TIME) for windows being mapped that
provide the timestamp of the event that caused the window to be shown.
 App writers obviously don't want to deal with this, so gtk+ has a
smart default which applications are allowed to override.  What gtk+
does is: When a new window is mapped for an app, it takes the last
user interaction with that app and uses that.  This works in most all
cases because most windows opened (a file open dialog, the preferences
window, etc., etc.) are all opened in direct response to a button
press or key press from the user.

Now, take the example of a window opened out of the blue (due to
network communications or the disk becoming full when trying to
autosave, etc.).  When these windows are mapped, the _NET_WM_USER_TIME
that gtk+ will set will be the last interaction that the user had with
the application that launched the out-of-the-blue window.  If that
application is the one that the user is typing into at the time this
out-of-the-blue window appears, then the window will be launched with
the timestamp of the keystroke that is processed just before the
gtk_widget_show() call.  Of course, the application could override the
gtk+ guess and specify that the timestamp for this given window should
be 0.  To do that, it would need to call

My question was just a list of all circumstances when the application
needed to override gtk+ and say that the timestamp should be 0 (or
perhaps even something else via calling
gdk_x11_window_set_user_time()).  I guess what you are saying is that
the rule for when to call that function isn't along the lines of "for
error and alert dialogs" but rather "whenever a window appears out of
the blue".      Hmmm.... I thought I had a counter-example or two for
that general rule that would require further qualification but I went
to type up one and found it was invalid and can't remember the other
(though maybe it's invalid too).  Perhaps the rule really is to call
gtk_window_set_focus_on_map() whenever a window will be appearing out
of the blue.  Anyone see any problems with that?


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