On 3 May 2006, at 17:19, Charles Moir wrote:
Some questions/point. Apologies for those living in the world of poor text, with no colour, but you should still be able to see where the comments are I'd hope.
Yes, I see them in colour, even!
I'll get back to you on this one... There's a distinction between having focus in a control in a modeless dialog (in which case the control can handle Escape and Return) and having focus in the dialog itself (which is now unlikely).
5. A modeless window should release focus when it has done its immediate job - it must not hold focus assuming the user will want it in that window again. This includes the focus given to a modeless top level window (e.g. colour editor) when it is dragged by its title bar - if it's not going to use that focus it should hand it back to the previous owner so that focus indication correctly shows where focus really is. The meaning of "immediate job" is defined by the window but a typical example is when the user presses Return after entering text into an edit control.
[Charles Moir] To clarify this means that dragging the colour editor, or any modeless dialog, would return focus on the drop (as the current colour editor does actually)
6. The user must be warned about any destructive operation caused by a keypress in a modeless window (unless the data concerned is owned by the window itself).
[Charles Moir] I don't understand this one. It's generally thought that good UI should not warn the user about operations that change data, because that's what Undo is there for. Ah, by destructive you mean really destructive, specifically that it destroys the undo record?
This idea was conceived when I was thinking about driving galleries via keypresses - to handle keypresses doing unexpected things to selected gallery items. But I can see that it's superfluous now. I'll remove it.
7. A window only gets focus as the result of deliberate action by the user such as clicking or pressing tab.
[Charles Moir] How would tab transfer focus to a window that didn't already have it?
A control might have focus and then you hit Tab to move focus to one of its siblings. (This may have been unclear because of the way I use the term Window to encompass controls and dialogs and other windows - Alex suggests a change here.)
The application should never move focus into a modeless window by itself.
8. A window should not take focus if it has no use for keypresses. Further, a control in a modeless window should only take focus if keypresses are essential to its operation.
9. A window should indicate whether it owns or contains input focus (or not) in the standard way for the native OS. This is usually indicated using the title bar or tab control.
[Charles Moir] Except docked windows appear not to do this
Yes. But as you and Alex have just discussed they probably should.