3 ms·

The problem is more complicated than it seems. Apps have to be allowed to take focus otherwise a newly-launched app wouldn't have keyboard focus. You'd click on

by spolsky 19y ago

The problem is more complicated than it seems. Apps have to be allowed to take focus otherwise a newly-launched app wouldn't have keyboard focus. You'd click on a link in your email and the web browser would come up but then you'd have to move the keyboard focus to the browser yourself. Usually these bugs are caused by someone fixing another bug. It seems even wronger when a dialog box or some other new window comes up, and the focus is not on it. This gets reported, and the programmer fixes the problem by taking focus.

reitzensteinm 19y ago
Well, there could be both a 'launch app and give focus' and 'launch app in background' so the caller chooses - in most cases the window manager, so for example items on startup don't clog everything up. You could probably take away the ability for an app to grab focus for itself (but an app with focus could assign focus) with no real loss - just mandate that the notification area be used instead. Of course, that's ignoring legacy apps, so it can't really be done (smoothly), but there probably is a clean, correct in hindsight solution to this problem. Then again, if they're going to break stuff just because in Vista... might as well add something useful! ------- Why can't I get Help from this program? The Help for this program was created in Windows Help format, which was used in previous versions of Windows and it is not supported in Windows Vista. For more information, see Windows Help program (WinHlp32.exe) is no longer included with Windows on the Microsoft support website.
tuukkah 19y ago
In cases where the new window isn't a surprise to the user, it can be given the focus. Generally speaking, I agree there are a lot of complicated race conditions in GUIs. Parts of solutions: more global undos and event logs, disabling controls for the minimum human reaction time, less invasive dialogs and event notifications, faster feedback...
ivankirigin 19y ago
The underlying platform in question is partially at fault here. Why do you need to restart immediately? Certainly if there were an imminent security fix to stop the spread of a worm, you could justify the notification to restart immediately. The real solution is to have a coherent security policy in the OS. Then things won't get urgent for automatic updates. Beyond updates, there shouldn't be much need to ever have an app take focus after already running. A visual notification like those little hopping icons in OS X works very well. Your point about an app taking focus makes sense. It's really a question of etiquette. A reasonable underlying system would allow apps to take focus, but it would less often be urgent and most likely in response to user input, not not interrupting.
crescendo 19y ago
The problem is recognizing user intentions and the appropriate time for a context switch. If I launch an app or click a link in an email, I clearly signal to the machine that I'm ready to start a new context. However, the machine itself initiates something like a software update dialog, so my own intentions never come into play. Making a context switch against the user's expectations is asking for trouble.
bk 19y ago
How about this: _User_ triggered apps/windows/dialogs are allowed to take focus, because it's clearly the user's intention to open/use that app. This does not hold true for automatic updater windows, such as update boxes, new chat messages, etc. OS X for example gets this half right, with the play sound and bounce dock icon features. The perpetually bouncing icons can drive me crazy, so the best solution would be if cmd-tab automatically put apps demanding user attention first in the open apps list, so that as soon as there's a dock bounce, I can get to it with one quick cmd-tab. That way I can get to it fast and I don't run the risk of the spacebar-ok|cancel disaster (which in minor forms has happened to me before too).

by spolsky 19y ago

reitzensteinm 19y ago

Well, there could be both a 'launch app and give focus' and 'launch app in background' so the caller chooses - in most cases the window manager, so for example items on startup don't clog everything up. You could probably take away the ability for an app to grab focus for itself (but an app with focus could assign focus) with no real loss - just mandate that the notification area be used instead. Of course, that's ignoring legacy apps, so it can't really be done (smoothly), but there probably is a clean, correct in hindsight solution to this problem. Then again, if they're going to break stuff just because in Vista... might as well add something useful! ------- Why can't I get Help from this program? The Help for this program was created in Windows Help format, which was used in previous versions of Windows and it is not supported in Windows Vista. For more information, see Windows Help program (WinHlp32.exe) is no longer included with Windows on the Microsoft support website.

tuukkah 19y ago

In cases where the new window isn't a surprise to the user, it can be given the focus. Generally speaking, I agree there are a lot of complicated race conditions in GUIs. Parts of solutions: more global undos and event logs, disabling controls for the minimum human reaction time, less invasive dialogs and event notifications, faster feedback...

ivankirigin 19y ago

The underlying platform in question is partially at fault here. Why do you need to restart immediately? Certainly if there were an imminent security fix to stop the spread of a worm, you could justify the notification to restart immediately. The real solution is to have a coherent security policy in the OS. Then things won't get urgent for automatic updates. Beyond updates, there shouldn't be much need to ever have an app take focus after already running. A visual notification like those little hopping icons in OS X works very well. Your point about an app taking focus makes sense. It's really a question of etiquette. A reasonable underlying system would allow apps to take focus, but it would less often be urgent and most likely in response to user input, not not interrupting.

crescendo 19y ago

The problem is recognizing user intentions and the appropriate time for a context switch. If I launch an app or click a link in an email, I clearly signal to the machine that I'm ready to start a new context. However, the machine itself initiates something like a software update dialog, so my own intentions never come into play. Making a context switch against the user's expectations is asking for trouble.

bk 19y ago

How about this: _User_ triggered apps/windows/dialogs are allowed to take focus, because it's clearly the user's intention to open/use that app. This does not hold true for automatic updater windows, such as update boxes, new chat messages, etc. OS X for example gets this half right, with the play sound and bounce dock icon features. The perpetually bouncing icons can drive me crazy, so the best solution would be if cmd-tab automatically put apps demanding user attention first in the open apps list, so that as soon as there's a dock bounce, I can get to it with one quick cmd-tab. That way I can get to it fast and I don't run the risk of the spacebar-ok|cancel disaster (which in minor forms has happened to me before too).