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

Re: [XaraXtreme-dev] Galleries and focus handling

Phil,


OK, I have tried to reconcile everyone's points to create a revised set
of rules (apols if I've missed some subtleties).


Some comments below inline


There are two basic ways of resolving the differences between the OS
implementation of focus and our streamlined version:
1. We can move OS focus to refer to the window where keypresses will be
first used
2. We can leave focus where the OS puts it and shuffle keypress events
around internally from there.
I think it's clear that the first approach is best - the OS will then be
in sync with the app and focus indication as shown by title bars will be
more correct. The rules are defined on that basis.


I do too. People should be aware that this will mean most dialogs
have grey title bars most of the time (indicating keypresses will
go to the app, not to them). They will go blue if (for instance)
the caret is in an editable field.


Definitions:
"Window" is any gui element derived from a window; typically a control
but could be a dialog or anything.
"Focus" means the focus window pointer maintained by the OS/wxWidgets.
That window is said to "own" the focus and is given first refusal of any
keypress events generated.
The "Active View" is the Camelot document view window in which the user
has selected nodes and in which selection blobs are being shown OR the
Camelot document view window that last had input focus.
"Modeless" == "Non-modal"
To "Claim" an event means to prevent it being sent on to other windows in
the command chain.


Define "Dialog" to mean a dialog, bar or gallery, docked or undocked.

You have used "window" below occasionally to mean a control, and
occasionally to mean a "dialog". I think we should eliminate "window"
where possible and go to "control" or "dialog". Window (where used)
should mean either.


Focus Handling Rules Revision 1:


1. A modal dialog owning or containing focus obviously consumes all
keypresses. The window owning the focus gets the first chance to use the
keypress, then parent windows recursively until the modal dialog itself.
(This should be the natural behaviour assuming the modal dialog is a "Top
Level Window".)


2. The active view can usually make better use of keypresses than any
modeless window and so a modeless window should claim the minimal number
of keypresses possible.


3. A modeless window owning the focus should only use keypresses if its
ownership of the focus is more prominently shown to the user than the
selection in the active view. (E.g. flashing caret, boldly shown selected
item or popped-up selector window)


I think that should say "A window that is, or is contained by a modeless
dialog". You've defined window to include "control", which themselves are
neither modal nor non-modal.


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


I think that one is meant to start "A window that is, or is
contained by a modeless dialog" as well.

The point re return seems to be controversial with Charles (though
I agree).


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.

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


Again "modeless window" doesn't exist as a concept using your definitions.
I think here you mean "modeless dialog".

I don't understand what you are advocating here - could you give an
example?


7. A window only gets focus as the result of deliberate action by the
user such as clicking or pressing tab. The application should never move
focus into a modeless window by itself.


We should note that pressing tab will only give a window focus if another
window (i.e. control) in that dialog already has focus, and it should
cycle only amongst controls that can take focus.


8. A window should not take focus if it has no use for keypresses.


I think that means a "control" should not take focus


Further, a control in a modeless window


"in a modeless dialog".


should only take focus if
keypresses are essential to its operation.


We need to define what "no use for keypresses" means. The space
bar toggle check boxes. I can imagine that the colour editor using
the space bar to toggle a check-box rather than toggling the
selector tool is going to be unpopular.


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.


I think that is a "dialog" should indicate

OK, you should also talk about the point that a *control* with focus
should have some visible indicator (a caret or a highlight) before
the following:


A window which can show selected
items when it does not have focus and which uses keypresses to act on
those items when it does have focus must render the selected items more
boldly when it has focus than when it hasn't. This helps the user see
that his keypresses will do something different when the window has focus.


I think that is meant to refer to a "control" but throughout, but
I'm not sure.


10. Mouse wheel events have nothing to do with focus or active windows -
they are sent to whatever control the mouse is over. Important: Neither
the OS, nor the application or any layer in between must be allowed to
set focus because of wheel events or because the mouse has been idle over
the window for any period!




Notes:
* All modeless dialogs should be dockable.
* All modeless dialogs should ideally immediately affect the active
drawing (e.g. the colour editor) or have Apply and Close buttons. It is
not correct for modeless dialogs to have OK and Cancel buttons.
* I'm assuming that there is a mechanism (OnSetFocus event?) which allows
a window to accept or reject focus.


You can just set it back to the mainframe.


I am mindful of getting all this stuff working in a platform neutral way.
As Alex points out it may be difficult to prevent the OS giving focus to
a window when it is clicked on and I don't think we should try to fight
that because it will lead to unreliable code and difficulty in porting.
Instead, we should rely on the focus handling rules set out below sending
keypresses to the appropriate location.


Areas which are not (it seems) covered in the above (because I
don't think we've reached consensus):

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

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

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

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

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

Alex