Re: [XaraXtreme-dev] Galleries and focus handling

[Alex Bligh <alex@xxxxxxxxxxx>]

Phil,

> 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
> implement.
>
> 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
> clicked.

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.

Alex