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

RE: [XaraXtreme-dev] Galleries and focus handling

Charles,


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.


No controls I know of make use of CTRL-W / ALT-F4 (unless you can
use CTRL-W to close the drop down menu on a pop-up box). Just about
all of them make use of RETURN (at least in some way). But as I said,
noone in their right mind is going to close a dialog by clicking
in a text field then hitting CTRL-W (they'd hit the close button).
Equally, I think if you clicked in a text field in the info bar (which
can't close anyway) and hit CTRL-W you'd expect the document to close.


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.

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.



Ah. But ALT-F4/CTRL-W are not relevant to the control. It doesn't
have to do ANYTHING. No values change etc. Just the dialog goes away.
That's (in my book) not relevant to the control. And as Phil's
guidelines say, if the keypress is more likely to be useful to the
document, it should be passed there. If CTRL-W is relevant to a
text control (as opposed to the dialog that it lives in), why
isn't it relevant to (say) a checkbox or a radio button? IE why
don't you let /them/ give the dialog focus etc. The answer is
"because it makes no sense for just these few keys".

The advantage of getting rid of this is then the (modeless) dialog NEVER
has to handle any keypresses. Only the control does.


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.


As it happens, I use escape to get rid of dialogs but recognize that will
have to go. I use CTRL-W to close documents down. I am not going to be
put out by having to use the mouse to close dialogs. If I really want
to close them on a keyboard shortcut, I will remember the keyboard shortcut
used to display the dialog. Hitting that again should remove it.

There is a downside, which is complexity. CTRL-W will sometimes close
the dialog (if the cursor happens to be in an editable field), and
sometimes the document. For some dialogs, CTRL-W can never work.

I am beginning to think what we should do is make these dialogs look
different and distinctive to the modal ones, precisely BECAUSE the
key handling is different. And we should avoid where possible any
use of "apply" and "close" buttons. They should all aspire to be
like the colour editor (i.e. all changes take immediate effect on the
page, no space wasted with buttons etc.) - they are in essence dockable
and floatable palettes.


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


But it WON'T happen! If the dialog has no editable fields or
combos, it CAN'T take focus! That's what we've spent today deciding
(which was your proposition). My original proposition was it DID
take focus (precisely so this sort of thing worked, along with
for instance ALT plus key-shortcut to hit buttons). But you've spent
the day convincing me that (for instance) there should be no
way to give focus to a dialog without combo boxes and editable
fields. I can't click on a control to give it focus. I can't drag
the title bar to give it focus. It doesn't get focus when it comes
up. The page keeps focus. So (assuming I have two of them up) which
of two such dialogs does Return go to?

Case in point. I have one dialog with 4 radio buttons in. Another
with 5 checkboxes in. Both have Apply and Close buttons. I open
both dialogs. I do something on the page. I now alter one of the
controls in one of the dialogs. I press return. By your own
guidelines, the dialog has not got focus (it has no blue title
bar). I press return. Where does the return go?

There is another possibility here, which is to have two types of
non-modal dialogs. Ones that are meant to be around for ages
(bars, colour picker, galleries) which NEVER have apply buttons
or close buttons (just the cross in the corner) and where the
dialog never processes any keys (just the controls within it). These
have the small title bar and are dockable. And "short lived" modeless
dialogs (like options is at the moment) which consumes ALL keys like modal
dialogs - the align dialog with its current UI would be a case in point;
this would look like a normal dialog but NO document keys would work.
To be honest though, I'd rather just make the align dialog modal
(or fix it's UI so it didn't have apply and close buttons, i.e.
worked like the colour picker) than do this.


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.


Sure. So the principle here should be that as far as possible ANY
edit in ANY non-modal dialog takes effect on the page immediately.
Combo boxes are obvious in that you chose from the dropdown and
they take place immediately (people don't realize you can type in
combos in general). So the only problem is editable fields, and
dialogs where (like the options dialog) certain combinations of
setting are illegal, so the commit has to be conditional. I would
suggest we make these modal.

The "big friendly apply button" is what makes the dialog ugly and space
consuming when docked. I agree with Neil that the align dialog (for
instance) would be better if it was interactive (somehow - haven't quite
got my head around the UI).

Alex