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

RE: [XaraXtreme-dev] Galleries and focus handling

Charles,


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.


Yes indeed. I pointed that out in the bit you snipped out.


> 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?



Sorry by "having focus" I mean "gets offered the keys first". It needs
to have focus in order for return to commit, Escape to cancel, when
the caret is not in (say) a text field. For instance, if you have
2 non-modals open, you'd expect that if you click on the title bar
of one, that one would go blue, and it would be the one that would
close if you pressed return, yes?

I did not mean it takes "all keys". I think we've all agreed that
there are basically the following states:
1. Modal dialog open - topmost modal dialog gets all the keys
2. No dialogs open - document gets all the keys
3. Non-modal dialog open, but the document is the thing last clicked
  on (I'm going to call that non-modal dialog not having focus) -
  document gets all the keys. Titlebar should be grey.
4. Non-modal dialog open, title bar just clicked, non-key-requiring
  control just clicked, etc. BUT NO KEY-REQUIRING CONTROL HAS
  FOCUS - titlebar should be blue, return and
  escape should take effect on that dialog (as opposed to their
  in-document meaning) - other keys should go straight to the document.
  In the case of a docked return and escape (in this scenario) are
  unused, so should be passed down.
5. Non-modal dialog open, focus in a key-requiring-control (e.g.
  a text control) - title bar should be blue, NO keys should be
  passed down to the document.

So when I'm taking about a dialog having focus, I'm talking about
1, 4 and 5. Note that state 4 is equivalent to state 3 where the
dialog (e.g. a bar) actually interprets no keys, apart from the
colour of the title bar when it is undocked, and that it takes
/away/ the focus from other controls.


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.


I think this is because you are using the word "focus" differently
from me. Some keys MUST go to the gallery (for instance where there
are drop downs). But unused ones would be passed to the document.

I'd fully expect CTRL-Z to be passed to the document in normal
terms, but if the caret was in a text field in a dialog (whether
a gallery, other non-modal or other non-modal), I'd expect
CTRL-X, CTRL-C, CTRL-V, CTRL-X etc. to do what they normally do
in text fields and combo boxes.

But I think although I'm /calling/ this the gallery having focus
(because it gets keys FIRST), when no text control is selected, it
doesn't PROCESS them, it passes them down.


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 the short answer is you wouldn't need to, as if you are outside
a control that uses keys (text control etc.) it will pass them on
anyway. The longer answer is do *ANYTHING* in the document with the
mouse (e.g. click on a new tool, drag on the page, use a bitmap button
etc. and it would take the focus). Think briefly not of a gallery,
but of the selector tool info bar. When would you expect the left and
right arrow keys to STOP going to the text control you have the
caret in? The answer is the same here.


> > 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. I agree. However the way the focus hierarchy works is then
the dialog/gallery has focus. ALSO even when they don't do have focus
return and cancel should commit/close the dialog (you said so
above).


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.


See return and cancel.


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?


No. You are missing what I'm saying. You open the layer gallery.
Pressing delete deletes the selection in the document because that
key is unused by the gallery EVEN THOUGH IT HAS FOCUS.

Open a gallery with a text control in. Click in the text control.
Pressing delete deletes text in the text control (not your
selection).

Open a non-modal dialog. Do not click in any control. Pressing ESCAPE
closes the non-modal dialog (as per your instruction above) and
does not clear the document selection, because RETURN and ESCAPE
are used by the dialog. The dialog HAS FOCUS though because it
takes these keys. But pressing delete DOES delete the selection because
it passes the key down.


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?


Delete deletes the selection. The arrow key nudges.


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.


It does NOT pass the focus back. You are imagining things! Just try
it! Draw some objects. Select all of them. Then open either the
tracer or the options dialog (I think this is true of any non-modal
except the colour editor).

Current Xtreme behaviour with non-modal dialogs
* Return commits the dialog (i.e. the focus is NOT passed back, the
 dialog takes the key stroke) WHETHER A CONTROL HAS A CARET OR NOT
* Escape cancels the dialog, or goes BEEP. It does NOT clear the
 document selection. IE the dialog has the focus.
* The arrow keys navigate between radio groups etc, AND do NOT get
 passed back to the document to do nudge
* The delete key does NOT delete the document selection

Now I think that the third and fourth of these are WRONG (and,
from what you've said, you agree, because you think it already
works this way, though it doesn't). But I think (apart from the
mysterious beep) that the first two are correct behaviour, and
I think you agree too - just I call that "the dialog having
focus but passing unused keys back". You call it "the document
having focus but control and enter are sent to the dialog". The
latter is not a correct characterization. If I said "well to
which of two dialogs that are open?" you'd have to say "urm, the one with
focus"!

Alex