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

Re: [XaraXtreme-dev] Galleries and focus handling

Charles Moir wrote:
The point re return seems to be controversial with Charles (though I agree). 

Hang on. What you're saying is that I enter a new value size value in
the Selector InfoBar, for example, press Return and *nothing* should
happen.

That's not going to work is it.


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.

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.


* We have not defined exactly when a non-modal dialog gets focus (as
  opposed to controls within it). In point 7 you refer to "clicking".
  Obviously if you click within a wxTextControl the dialog gets focus.
  It is not evident whether clicking on the title-bar or a different
  control gets the dialog focus (in which case unhandled keys would
  be passed down) or whether those do not give it focus (in which case
  keys go to the current view). The difference is in the processing
  of ALT-F4, CTRL-W and RETURN. Do these go to the document or to
  the dialog? If clicking the title bar does not give focus to the
  window, then how do such dialogs ever get focus to process these
  keys?


Well Phil's rules say that once it's done it's job it hand focus back
and so clicking and dragging a window could be regarded as completing
it's job (being moved), so it should hand focus back afterwards.


That is consistent with the rest of your argument, yes.


I can't see why it's an issue even for dialogs that do not have editable
fields. Why would you want to give it focus even, or rather why would
you want Alt-F4 to close the window ever (if it doesn't have focus, it
hardly makes sense to first click on it and then press Alt-F4, when you
could just click directly on the close box. Return would have no purpose
because there's nothing to commit. Esc ditto - it would have no meaning
on a dialog that has not had any edit just done to it (there's no
operation pending to cancel).


EXACTLY MY POINT! I am saying if it's so hard to give these dialogs
focus anyway (some CAN'T get it because they haven't got a wxTextControl
or a combo box, the rest you HAVE to click in a SPECIFIC control
anyway), there is NO POINT to keyboard shortcuts for commit and
close window, because you HAD to use the mouse to give the dialog
focus in order to use the keyboard shortcut! No-one in their right
mind would do that. Note RETURN would still "do the right thing" in
info bar fields because that is not a "soft commit" of the whole dialog
(it's not "pressing the default action button"), it's a keypress that
just affects that control.


* Do we need ALT-F4, CTRL-W and RETURN handling in non-modal dialogs
  (per se) at all?


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). 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. But if you DO click
in it, why not just click on the close box or apply button!


Or should non-modal dialogs ALWAYS act when the
  field is committed, and not have a concept of dialog state, in which
  case RETURN (at least) is useless.


Don't understand that. Return does the commit. See above.


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.

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

Alex