RE: [XaraXtreme-dev] Galleries and focus handling

["Neil Howe" <NeilH@xxxxxxxx>]

> >> 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).
> 
> Well if there is no way to GIVE a dialog focus so that return and
> escape act as commit and cancel, then they should NEVER work as
> commit and cancel - surely? But that would be a significant change
> from Xtreme, where escape and return do the expected thing (cancel
> and commit) on all non-modals.
> 
> That would be once conceivable option. It would have the merit
> of great simplicity. It would also (oddly) be closer to the UI
> guidelines in a way. Return and escape are meant to do "OK" and
> "Cancel". But our dialogs in general have "Apply" and "Close" - these
> are different in character. So arguably return and escape should
> not activate them in the first place. I'd be happy with this
> as a universal standard.

Yes, this is good. 

Aside: Why does the align dialog need an apply button anyway? Why can't
it work on the fly as you select the alignment options, like the color
editor? Even as it is I don't think it will be a big loss if you can't
hit return or cancel instead of hitting the Apply and Cancel buttons.

And Luke says that making it so that only the main window and text/combo
controls get focus should be an easy change. Am I right in thinking that
that's all we need to do or am I missing some complexity here?

> 
> >> 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).
> 
> It should do nothing. My point is that writeable combos take letters
> and the delete key. Read-only combos take letters (to select the
> first item beginning with the letter pressed) and but don't
> use the delete key (or could take nothing at all). Assuming read-only
> combos take keypresses at all, it would be most confusing if they
> passed down delete if they didn't use it, as that would delete
> the user's selection, and would be unpredictable as the user would
> not know that the combo box was write only at the time. Think about
> the multi-purpose combos in the fill tool. In read only combos you
> can still click the edit field and do CTRL-C for copy. If that's
> going to work, it would be bizarre for clicking the edit field and
> pressing delete to have an unpredictable action, depending on whether
> the combo happened to be read-only. That's why I'm advocating the
> "taking focus" behaviour to be dependent on the control, and whether
> a blue highlight / caret appears, rather than on the particular
> attributes of the instance of the control in question.
> 

Yes I agree. So combo boxes would take focus whether read-only or not.

Neil