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

Re: [XaraXtreme-dev] Galleries and focus handling

Phil,


I propose to clarify the rules to say that in Modeless dialogs:
* The Return keypress should commit uncommited values and should be
thought of as being associated with an Apply button, whether an Apply
button exists or not and whether it's labelled Apply or not. The  Return
keypress should return focus to the Active View.

* The Escape keypress should abandon any uncomitted values and should  be
thought of as being associated with a Cancel button as above. The  Escape
keypress should return focus to the Active View.
* Neither keypress should close the dialog.

I could also say that a modeless dialog or its controls may choose to
interpret other keypresses as commands to close the modeless dialog
according to whatever seems best under the native operating system
and/or hotkey configuration???


That wasn't quite what I understood. I've set out my summary below,
plus answers to my own questions. They need reordering (I think
these 5 go below the answers to my own questions), but I think they
are in a format capable of incorporation.

* In modal dialogs, CTRL-W, ALT-F4, Return and Escape are treated
 as per the operating system defaults.

* As non-modal dialogs do not gain focus except when a keyboard editable
 control [needs definition, see my suggested text below] has
 focus, key shortcuts such as CTRL-W, ALT-F4, Return and Escape may
 not work in non-modal dialogs unless such a control has focus, unless they
 are handled by the window manager itself. Where they do take effect,
 their actions are explained below.
* If a keyboard-editable control within a non-modal dialog receives a return 
 keypress, UNLESS IT PROCESSES THE KEYPRESS ITSELF it should
 commit the contents of the current field. [this handles the bar
case]. If there is a default action (e.g. an apply button), it should also 
 perform that default action, in which case the default button should
 be highlighted in some way so it is obvious which "apply" action will
 take effect. Examples of where a control processes return itself are
 (a) a multi-line text control where return should merely enter
 a return in the multi-line text field, (b) where the drop down list
 of a combo has been brought up, and return is used to select the
 item within the list.

* If a keyboard-editable control within a non-modal dialog receives an
 escape keypress, it should UNLESS IT PROCESSES THE KEYPRESS ITSELF
 cancel any changes to the current field (restoring it to the previous
 value, and then return focus to the selected document. An example of
 a control processing the escape keypress itself would be a combo box
 where the drop down is popped up, where escape should close the
 drop-down (in this instance, a second escape would return focus
 to the document).

* I a keyboard-editable control within a non-modal dialog receives a
 CTRL-W or ALT-F4 keypress (or other OS 'window close' keypress), it
 should process it, cancelling any changes. IE the effect should be
 the same as pressing ESCAPE then clicking the close button.

And here are the answers to my own questions:


* Should modeless dialogs LOOK different from modal-ones, to indicate
  that they are different beasts - suggestion: thin title bars - galleries
  should have these anyway.


* Non-modal dialogs should look different from modal ones to indicate
 that they behave differently. They should have thin title-bars, like
 galleries on Xtreme. The colour of the title-bar should reflect whether
 on not the non-modal dialog has keyboard focus. This will depend upon
 whether a keyboard-editable control within the dialog has focus. Unless
 this is the case, the non-modal dialog will have a "no focus" title-bar
 (normally grey).


* Should there be a simple list of controls that take all keystrokes
  when they have focus? IE is it a simple binary decision? We at
  least know this is implementable. If so, which controls are on the
  list. I have wxComboBox and wxTextControl. This precludes all need for
  the "pass the keystroke down" logic because these consume all keys
  (when they have focus), and other controls simply can't get focus
  in the first place.


* 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).


* We have not defined exactly when a non-modal dialog gets focus (as
  opposed to controls within it). In point 7 you refer to "clicking".
  Obviously if you click within a wxTextControl the dialog gets focus.
  It is not evident whether clicking on the title-bar or a different
  control gets the dialog focus (in which case unhandled keys would
  be passed down) or whether those do not give it focus (in which case
  keys go to the current view). The difference is in the processing
  of ALT-F4, CTRL-W and RETURN. Do these go to the document or to
  the dialog? If clicking the title bar does not give focus to the
  window, then how do such dialogs ever get focus to process these
  keys?


* 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.

* All controls can have focus in a modal-dialog (i.e. the normal OS
 rules are used).


* We have not defined the behaviour of ALT-F4, CTRL-W and RETURN when
  the focus is in a control that truly takes focus. For instance,
  consider a wxTextControl. Return there (if the text control is
  multi-line) does a new line. In a bar, it does a soft-commit of that
  field (but not other fields).


See above.


* Do we need ALT-F4, CTRL-W and RETURN handling in non-modal dialogs
  (per se) at all? Or should non-modal dialogs ALWAYS act when the
  field is committed, and not have a concept of dialog state, in which
  case RETURN (at least) is useless.


See above.

Alex