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

Re: [XaraXtreme-dev] Galleries and focus handling

The problem with focus handling in Camelot is that Charles is right...

Charles's concept of focus handling helps produce the streamlined app that users admire.


That currently produces an app that doesn't strictly adhere to UI guidelines and maybe that's partly why some people see it as "quirky".

So far we've never managed to resolve those two things and I don't have an answer now either but it would be great if there were a way to streamline the workflow so you're not "stuck" in a modeless dialog when you don't want to be while also allowing modeless dialogs to use keypresses as UI guidelines would expect.

There are two other contributing factors that perhaps we should take into account: Disabled users and mac users. Disabled users may need keyboard access (and there may be laws about this???). Mac users will expect the app to adhere more closely to UI guidelines than perhaps other users do.


On 3 May 2006, at 09:24, Phil Martin 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:

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

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

Oh, and:
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 next 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 editable
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 Windows) and no Ctrl-W should not close it because it should never have focus to be
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
down well.

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
keystroke to
the page if it doesn't use it (for instance the RETURN case
above). If
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
themselves handle.

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 would
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
because they
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 day.

Yes it has to. An editable field, is by definition, what makes a dialog need focus, briefly for the life of editing that value, and at no other

You just need to try and use other software that has traditional dialog
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 delete
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 user has a blinking caret in the field, and even then all unused key presses should be passed back. Doing anything like Enter, Esc passes focus back. Dialog with no editable fields should not be able to have focus at all.
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 dialog),
must not leave focus in that window.