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
way,
yes?
Yes.
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
current
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
time.
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.
Charles