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

Re: [XaraXtreme-dev] Galleries and focus handling

Charles,

> cross-purposes

Yes indeed. I don't think we all mean the same thing by the word "focus"
for a start.


Alex said (in a later email)

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?


No. Because this means just moving, say the colour editor window, would
leave focus in the window and so stop things working in the document
(e.g. Esc should clear the document selection, Return key also does
thing in the main document). So non-modal windows should only show title
bar focus if the caret is placed in an editable field (Xtreme doesn't
always show title bar focus even). Clicking or dragging on a window must
*not* give it, or any control in it, focus.


No it would not (in my way of doing things).

Suppose you click in the document, do stuff, then
move the colour editor. The DIALOG would get focus (or what I call
focus) and pressing return would OK it. However as no CONTROL
would have focus, it wouldn't make any difference to any key the
dialog itself didn't consume (i.e. "Return"). If you want Return
to work in non-modal dialogs, clicking on the title bar MUST determine
which dialog takes it.

The colour editor appears to be an exception here, but isn't simply
because it has no return or cancel key (it's like a floating bar
in that respect), so giving it focus makes NO difference, other
than the colour of the title bar, UNLESS you click in a control
like a text edit field. So with my suggestion the colour editor
works out the box. So does the arrange dialog and the options
dialog. The options dialog process return and cancel simply because
unlike the colour editor it has OK and cancel buttons.

Take two dialogs that are meant to do something on pressing return.
Options Dialog, Align, DocumentInfo, Tracer, whichever you pick.
Return closes them (right now, in Xtreme). Surely clicking on
the title bar must determine /which/ closes.


Alex said;

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


Er, did I say that?  If so that's wrong. As above. If an actual control
had focus (you've edited some values or moved the selection on a menu,
or are dragging a slider) then Esc should cancel that operation, return
control to the main canvas, but not close any dialog.


What do you mean by "an actual control". Could that include a radio
button? Currently in Xtreme, pressing Escape closes dialogs, pressing
return does a commit. That seems right. When the caret is inside
a combo box or text control, somthing else can happen.


I treat combo boxes and menus as editable fields. i.e. they can have
focus if the user has clicked on the control, so you can keyboard drive
a combo box menu at this point. Selecting a menu option, like pressing
Enter in a classic text field, would transfer control back to the main
document. See the Xtreme Text tool font menu. You can type on this
(quick short cut to the desired font), and use arrow keys etc, but only
while the menu is up (i.e. it clearly has focus). Pressing tab in an
editable field would transfer focus to another editable field in a
group, but to no other control.


Not even to a combo box? Surely focus should cycle around those controls
which can take focus when you press TAB (i.e. editable fields, combos,
possibly dropdown lists).


Oh and obviously (I hope) when a control does have focus, then it should
take all keys that makes sense to it, so all the normal edit, arrow,
delete, esc etc should all work in that control and not on the canvas.


I think it should also take those that don't make sense to it. See
delete key in read-only combos, for example.

Alex