RE: [XaraXtreme-dev] Galleries and focus handling

["Charles Moir" <CharlesM@xxxxxxxx>]

Alex said

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

No, I'm not sure this is what you want. Because just moving the dialog
out of the way a bit, stops your document editing working.  I'm in the
text tool typing away, I move the Document Info dialog out of the way a
little, and now I can't type (or at least Return and Esc don't do what I
expect).

In the align dialog right now, if I move it a bit, I can't even use the
arrow keys to move my objects any more either, as that changes the
selection of one of the drop-downs that's randomly got focus (we
probably all agree this is wrong).

Worse we continue to give every indication that the objects in my
document are selected and have focus (e.g. selection blobs around the
objects). So if my arrow keys really are not going to apply to the
selected objects on the page (or delete or whatever) we should be
showing this on the selected objects. The usual method is to grey the
selection indicators (which we cant do).

So I rather think the easier solution is that we do not give focus to
dialog by clicking on them. This would mean all key operations continue
to work on the main document all the time, *except* when focus is
clearly in a control. At that point typing Alt-F4 or Ctrl-W would close
the dialog (Esc never would).

So Camelot actually gets this wrong, in my view.

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

Well they would stop Esc and Return from working in the document.

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

Well I don't think it's right that pressing return should close these
dialogs (well it's certainly not right for the colour editor or
galleries). Even the Align dialog I should be able to click on the align
menu, cursor to the required option, press return to action the
selection, but I really, really do not want that dialog to go away on
that operation. Isn't the whole point of non-model dialogs is that they
do not need to go away, indeed they should remain around up until
explicitly closed.

The Options dialog again seems to be an exception. I suspect if we made
this one modal, no one would ever notice even, and that's probably
better than removing all key driving capabilities from it.


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

Yes, as mentioned above I'm treating combo boxes, menus as 'editable
fields'

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

Er, what does Delete do in a read-only combo? Right now it seems to do
silly things, so isn't this a case where the control should NOT take
Delete key, and should pass it back to the parent (or perhaps take it
but no to delete read-only menu options).

Charles