[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Galleries and focus handling
- From: Phil Martin <phil@xxxxxxxx>
- Date: Wed, 3 May 2006 09:24:18 +0100
- Subject: Re: [XaraXtreme-dev] Galleries and focus handling
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:
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.
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.
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)
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
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.
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.
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.
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.
On 3 May 2006, at 01:55, Charles Moir wrote:
I agree. We need a clear policy for all non-modal dialogs.
Otherwise we'll end up with inconsistent behaviour.
I think we should fix this properly so ALL dialogs behave the same
And I agree as well. Well for all non-modal dialog. Modal ones are a
different matter entirely.
So just clicking on a slider should not give it focus. Then
if the slider really does have focus (because the user tabbed
to get there) then it should respond to the arrow keys.
Er, except that Tab is required in the document (moves selection to
object). So yes it's useful to be able to tab between editable fields,
but I do not agree that it's useful to tab between other types of
controls. Well it can be useful but the price is too high.
Bzzt. Take the line gallery. It has a line-width field you
can enter a
value into. If that's not "taking focus" I don't know what is.
Yes you're right, so it's treated as any non-modal dialog and returns
focus on Enter. Strangely on Xtreme putting the cursor in this
fields does not show the gallery window as having focus. I suspect
that's probably not really correct or necessary.
However, even that isn't quite all. Presumably RETURN should commit
the changes in a non-modal dialog (Should escape cancel it? Should
CTRL-W close it?).
Yes return should commit and yes Esc should cancel (does on
no Ctrl-W should not close it because it should never have focus
closed (except when the cursor is in the field). So anyone expecting
Ctrl-W (well actually Alt-F4) to close the dialog they think has focus
will simply result in the main document being closed. That won't got
So it sounds to me like what is happening is the
windows CAN get focus, but just not controls within them.
No, don't see that. Why does a window have or need focus?
And if no
control has focus within the window, it should pass the
the page if it doesn't use it (for instance the RETURN case
a control DOES have focus, I don't know whether it should pass an
unused keystroke on. Hmmm...
Yes it absolutely *must* pass all unknown keys on. E.g. the current
galleries stop F-key tool change short cuts working. Can't have that.
Also any gallery that shows a list of items (layer gallery,
color gallery, font gallery) should really allow the user to
scroll through the list using the arrow keys. So I think
galleries and in general ALL non-modal dialogs should take
focus. It's just that they pass on events that they don't
No - this is the exact example I listed earlier. The last thing I want
is arrows key short cuts NOT moving objects on the canvas. We have
highlighted gallery items right now, and the program would become
unusable if a range of common key short cuts stopped working. What
you do with Ctrl-Z - would this undo the last gallery change? Don't
think anyone would ever expect that.
And if the gallery did have focus, how do you get it back into the
document without altering the selection? No, this could not work.
Well galleries can presently get focus and that's wrong
have no need to ever have focus. And that's what's causing the
gallery problems I suspect.
They do - see line gallery, name gallery et al.
OK we should do just as in Xtreme is at the moment (that has it 90%
right), editable fields should have focus only when clicked in, but at
no other time.
Yes. And we shouldn't have to change the way any gallery
window works just because we decide to add a text field to it one
Yes it has to. An editable field, is by definition, what makes a
need focus, briefly for the life of editing that value, and at no
You just need to try and use other software that has traditional
and the traditional focus nightmare (confused users, twice as many
clicks to do anything, lost selection and more) to see why our tool is
so much more productive.
OK imagine this scenario. You spend ten minutes carefully selecting 50
objects, and want to adjust something in a gallery, say adjust layer
visibility. Were clicking in the gallery to give focus to the gallery
then a) the canvas selection would have to be cleared (you can't have
the concept of two selections) and b) pressing the Delete key to
the selection would what, delete the layer you just clicked on?
Or you carefully select 50 objects and want to adjust their size /
transparency / blar so you click a slider to adjust the value, and now
press delete? Or press arrow key?
So it quickly becomes obvious that anything that takes focus away from
the canvas produces severe usability problems.
So Xara has it right. Non-modal dialogs can only keep focus if the
has a blinking caret in the field, and even then all unused key
should be passed back. Doing anything like Enter, Esc passes focus
Dialog with no editable fields should not be able to have focus at
Certainly doing thinks like clicking and dragging on such dialogs
(colour editor layer gallery etc etc) should not leave focus in the
dialog. And certainly just moving a window (gallery, non-modal
must not leave focus in that window.