RE: [XaraXtreme-dev] Galleries and focus handling

["Charles Moir" <CharlesM@xxxxxxxx>]

> No no. I am saying return should commit the FIELD (i.e. the 
> control) but not the other contents of the dialog. In my mind 
> in any normal dialog, anything else that has changed should 
> ALREADY have been soft-committed on the page. IE if you 
> change a radio button or a checkbox setting, it should happen 
> there and then, and not wait for you to need to hit "Apply" 
> (or press return). If this doesn't happen, perhaps your 
> dialog should be modal. But pressing return should do 
> something in the CONTROL, i.e. commit the value you've just 
> entered in a text field. That's EXACTLY how the selector info 
> bar works. Return does not "commit" the contents of the info bar.
> It commits the contents of the field that has changed. 
> Similarly it's how the colour editor works at the moment.

Oh OK fine, but then we need clarification in the rules doc about the
difference between a field commit and dialog commit.

> What we would lose (by losing generic return and CTRL-W / ALT-F4
> processing) is the ability to hit the default action button 
> (or more precisely, it would no longer be a default action 
> button, just a button). Pressing return in a text field (or 
> combo box) would still commit that control's value. Equally 
> we'd lose the "default dismiss" option. Given that in your 
> world, we can't press those ANYWAY except specifically by 
> clicking in a text field (they won't work after the dialog is 
> brought up by default, after clicking on any other control, 
> or having clicked on the title bar), and they won't work in 
> any dialog which has no text controls or combo boxes (because 
> they can't get focus) I am arguing we don't lose much, and 
> gain a lot of simplicity.

OK I think I get it. Go for the simplicity case then.

.....

> > Oh yes close Windows short cuts are useful and standard. So that 
> > Alt-F4 should close the dialog, irrespective of whether 
> it's modal or modeless.
> 
> But if it's modeless, you can't give the dialog focus unless 
> it's got a wxTextControl or a Combo box in, and you click in 
> it. By your own logic you want CTRL-W to go to the page (just 
> like the arrow keys, space bar etc. do).

Well only if the control doesn't make use of them, and in fact it almost
certainly will make use of all those examples.

> You've said if you 
> click the title bar, it lose focus afterwards! So unless 
> there is a text control or combo, and unless you click in it, 
> the dialog won't SEE the keypress.

Yes but if you do click in it a field, we've said the control should
handle all key presses that are relevant to it, and Alt-F4 should mean
'close this dialog'.

Otherwise, if you don't click in a field, then you can't give focus to
the dialog and thus those keys will go the document anyway.

> But if you DO click in it, 
> why not just click on the close box or apply button!

Well yes that's true. But I suspect some people out there do click in
editable fields and press Esc to close the dialog (which would now have
to be Alt-F4). If even some users expect that, then we should do it
because there's no downside, and it's consistent across modal and non
modal and indeed all apps.

So as I say the rules say the control should handle what are useful and
so I'd say in this case (and it only applies where they've give focus to
a control) that these short cuts can be regarded as useful still.

> I think we are getting confused between committing the field 
> value (like the way the selector tool info bar works) where 
> each field affects the document, and there being some "dialog 
> copy" of the values, which might be (in toto) invalid, which 
> is separately committed using a default action button (a la 
> RiscOS, and like the Options dialog). Similarly I'd kill 
> return operating (for
> instance) the "Trace" button on the trace dialog in the event 
> it stays non-modal.

Yes I am getting confused, as is probably everyone who's reading this.

> If we agree non-modals should be dockable, think about 
> whether we really want them to have default action buttons anyway.

Yes surely it makes sense. i.e. the Apply button is what happens when
you press Return. So it should be there and highlighted to indicate this
(as is standard GUI). I've seen lots of users who don't even understand
they have to press Return in a field to action it, and so a nice
friendly big Apply button solves that problem.

But you only need to see new users struggling with the InfoBars to
realise how much we take for granted and regard as obvious, which is
anything but.

Charles