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

Re: [XaraXtreme-dev] Galleries and focus handling


6. The User is in charge
A control or dialog only gets focus as the result of a deliberate action
by the user such as clicking or pressing Tab while the focus is in a
control to move focus to another control in the same dialog.
The application should never move focus into a modeless control or dialog
by itself. An example of this is when opening a new modeless dialog: the
application should not automatically move focus into that dialog or any
of its controls.

I think the second line here is confusing. "Such as clicking" means
what? Clicking on the title bar doesn't do it. Clicking on the dialog
background doesn't do it. Clicking on a non-keyboard-editable control
doesn't do it (even in a loose definition thereof). Perhaps just
"clicking in a control capable of taking focus".

7. Focus only when needed
A control or dialog should not take focus if it will not claim any
keypress events. Further, a control in a modeless dialog should only take
focus if keypresses are essential to its operation or if the control is
in a mode where keypresses are useful.
Example1: A radio switch in a modeless dialog should not take focus when
clicked on and it should prevent itself from being in the tab sequence.
Example2: A combobox in a modeless dialog should not take focus in its
normal state but could do so when the popup list is open to allow
listitems to be selected using keypresses.

That's wrong! It does take focus its normal state so you can edit the
edit field. I think you mean "dropdown" rather than combo, but I thought
we decided all of these should behave the same (even in a drop-down,
i.e. a read-only combo, you should be able to select text and press
CTRL-C - but really this was for consistency as the user won't know
it's readonly). Perhaps best just to drop this example as combos are
perhaps the most complex example.

c. It may be determined that all controls either claim all keypresses or
none, in which case "Rule 3. Minimal keypresses" becomes simpler to

Alex asserts: Controls fall into two categories: keyboard-editable
controls and non-keyboard editable controls. The former can take focus in
non-modal dialogs (and include text controls and combo boxes). The latter
cannot. A corollary of this is that the keyboard cannot be used to
control non-keyboard-editable controls in non-modal dialogs (for instance
check-boxes and radio buttons).

Alex asserts: When a non-modal dialog has focus, focus necessarily
resides within a keyboard-editable control. Pressing TAB will cycle focus
around keyboard-editable controls ONLY. A non-modal dialog with no
keyboard editable controls cannot gain focus. Clicking on a title bar of
a non-modal dialog does not give it focus. When a non-modal dialog is
created it should not have focus until a keyboard-editable control is

Indeed. I can't see how it's possible to avoid this without subclassing
all the controls and saying "would you take key X in your current
state". Unless anyone has any great ideas re this, we could agree the
implementation and change "It may be determined" to "it has been
determined" etc.