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

RE: [XaraXtreme-dev] Galleries and focus handling

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.

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?

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?

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?
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