[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Galleries and focus handling
- From: Luke Hart <lukeh@xxxxxxxx>
- Date: Wed, 03 May 2006 10:07:03 +0100
- Subject: Re: [XaraXtreme-dev] Galleries and focus handling
Comments on current state inline.
1. A modal dialog with focus obviously consumes all keypresses. The
control with focus gets the first chance to use the keypress, then
parent windows recursively until the modal dialog itself.
Works, modal is a Top Level Window so get all user interaction.
2. A modeless control owning the focus uses only the keypresses it
needs (see rules 3 & 4) and passes all others on through a chain in
this order: control, control parents (recursively), active view,
active document, application.
This isn't quite the case at the moment. For example if you give an edit
box focus, it takes all input. There is no way (currently) to tune what
keys a control instances takes, and only rudimentary tuning of control
types (either a type of control takes all or takes none)
3. The assumption is that the active view can usually make better use
of keypresses than any modeless control and so the control should use
the minimal number of keypresses possible.
4. A modeless control 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 or boldly
shown selected item)
That makes sense. Outside of the scope of what I've implemented though!
5. A modeless control should release focus when it has done its
immediate job - it must not hold focus assuming the user will want it
Pressing 'Enter' puts the focus back into the document. Escape doesn't
do likewise, yet.
6. The user must be warned about any destructive operation caused by
a keypress in a modeless control even if the operation can be undone.
7. Mouse wheel events have nothing to do with focus or active windows
- they are sent to whatever control the mouse is over.
That's a very good point, but probably not in the way you meant it! It's
traditional for X applications to also give focus to the control that is
under the mouse, i.e. keys go to it. I don't think Gnome allows
replicating this behaviour, but I think KDE might!