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

Re: [XaraXtreme-dev] Galleries and focus handling

Phil,

--On 03 May 2006 09:24 +0100 Phil Martin <phil@xxxxxxxx> wrote:


We have discussed focus handling many, many, MANY times during the
development of Camelot!

A set of rules would make it easier for developers to get to grips  with
focus handling and I think the basic rules are these:


Yep. See the "five states" for user perception thereof.


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.


Yes


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.


By a "modeless control" do you mean "a control that take a caret" or
"any control in a non-modal dialog"? I think you mean the latter.

Equally the dialog ITSELF can (I think) have focus when no control
does (e.g. if the control that has focus becomes greyed). I believe
the dialog itself does ENTER and ESCAPE key handling. It should,
if not modal, and if it gets a key directly, pass it on to the
active view, document, application if it does not need it itself.


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.


I think the world will probably be a simpler place if controls either
take all keys, or no keys. Hmmm... with the possible exception of
RETURN and ESCAPE or commit and cancel aren't going to work. It
would be daft if (for instance) a control with a validator string
for numbers took only numbers but letters went to the page.


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)


True. I'd add that the modeless control's parent TLW should have a focus
indicator in its titlebar too (that's the main frame in the case of a
docked bar, but the titlebar of a floating bar, dialog, or floating
gallery). That should be subject to the exception that docked galleries
could indicate this using their pseudo-title bar (the thing that looks
like a title-bar with a close button on).


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
again. (?)


How do you know when it has done its immediate job? I think what you
mean is a commit in the control should cause it to lose focus (like
pressing return in a selector bar edit field causes the caret to
go away).


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


Is (for instance) deleting 200 characters in a text control destructive?
I don't think I'd want that to warn. Is selecting (using the arrow keys)
a different font in a combo box destructive? I don't think I'd want
that to warn. I think this one is unnecessary. I can't even think of
when it would be useful.


7. Mouse wheel events have nothing to do with focus or active windows  -
they are sent to whatever control the mouse is over.


Yes, wxWidgets sorts that out.

However, note some linux systems are set up to give focus to the mouse
under the window automatically, or after the pointer has been idle
for a specific length of time. I suggest we ignore these for the
time being!


There's leeway within those rules to fine tune things, such as what
happens when a gallery item is selected.

I think selected gallery items are the biggest problem in focus
handling: When you're immediately thinking about them you want to be
able to use keypresses to handle them - especially Delete! However,  if
you're thinking about the drawing while a gallery item happens to  be
selected you don't want a keypress intended for the drawing to be  used
by the gallery.


I think agree with Charles here (if I understand him right). Just don't eat
delete etc. - too dangerous. IE the gallery control should NOT need
keys consistent with your rule 3 above, so under rule 2 delete should
go to the document. There is no flashing caret to indicate otherwise.
Part of the issue here is that the layer gallery (and to some extent
the colour gallery) are confusing, because the "selected" layer means
both the layer a keypress would act upon (and indeed that the buttons
DO act upon), and the insertion layer. So you can't work on the document
without a "selection" in the layer gallery, which if it were to count
as a "flashing caret" would mean it consumes key presses.

I could be persuaded otherwise if gallery focus was handled right and
you got some indication of where the keystroke was going to be. This
would never work on Xtreme which ALWAYS seems to have blue title bars
for galleries, despite them hardly ever taking any keys.


We could make it a user option whether gallery items respond to
keypresses or not and, when they do, ensure that their selection is  more
prominent than the active view by drawing a flashing box around  them.
But that could be annoying and adding a user option is a cop- out and
should only be a last resort.


I think that's options in lieu of solving the problem!


BTW, Charles: Note that you /can/ have the concept of different
selections at the same time in different windows - many programs do
that. The selection in one window remains in place but becomes dimmed  or
greyed while the focus is in another window and when focus is  returned
that selection is retained and becomes undimmed. If we did  that fear of
loss of selection in the active view wouldn't have any  impact on the
issue of focus handling.


It already happens in Xtreme. Just select some text in a text control
when there is a selection on the page.

Alex