Re: [XaraXtreme-dev] Galleries and focus handling

4. A modeless window owning the focus should claim only the keypresses the user expects to work in it, even if some of those keypresses are ignored. For instance, a text edit control may claim all alphanumeric chars even though it only uses digits. All unclaimed keypresses should be passed on through a chain in this order: window, window parents (recursively), active view, active document, application. A modeless dialog which owns or contains focus should not use Escape to close itself or Return to commit uncommited values (see notes below).[Charles Moir] Esc should always mean cancel the edit in progress

Why would Return not commit the values? Surely it should?

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)

Yes.

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.