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

RE: [XaraXtreme-dev] Galleries and focus handling

Charles,

--On 03 May 2006 16:23 +0100 Charles Moir <CharlesM@xxxxxxxx> wrote:


Alex said

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?


Well there is a way to give a dialog focus, click in one of it's
editable fields, and no other way.


And if it has none? How would return/escape work then? (though we earlier
seemed to be coming to the conclusion the answer is they never do anything).


But that would be a
significant change from Xtreme, where escape and return do
the expected thing (cancel and commit) on all non-modals.


I say they do not do the expected thing. Return should do the default
dialog action, and indeed if we make this Apply (as it should be in
non-modal dialogs) then this solves that problem anyway.


Ummm.. except that you can't actually give a non-modal dialog with
no editable fields focus in your way of doing things.


Esc I do not believe should remove a non-modal dialog. There are more
compatible keys for this (Ctrl-W and Alt-F4 - and I think we should
support both), but *only* if there is focus in a field.


So if the cursor is not in an editable field (or combo etc.) return,
ALT-F4 or CTRL-W do nothing. And the consequence is if the dialog
has no such controls, they cannot be controlled/committed by the
keyboard.

BTW on linux applications anyway (and Firefox under windows
at least) CTRL-W closes the current tab (i.e. the document) whereas
ALT-F4 closes the window (i.e. the mainframe). So yes in a dialog
I presume they should both close the dialog.


Which is fine. But right now the gallery window title bars do get focus
(blue or orange) and that's inconsistent with the fact that key presses
etc are really going to the main document. And I can see on LX presently
it does take focus away from the main window (gallery title becomes
orange, main window goes grey). Except when it's docked in which case
that doesn't happen. So that's very inconsistent as well.


Oh sure, no-one is (I hope) pretending the current LX behaviour is
right. I certainly have not bothered trying to get it right as the
Xtreme behaviour is to me inconsistent and counterintuitive. I have,
however, hopefully made it so it is fixable in a small number of
centralized places.


In your model, I
think non-modal dialogs NEVER process return or cancel (which
would mean return would not work to apply the changes).


No in my model they would process all key presses that are relevant to
them when they have focus (i.e. the user has clicked in a field). As it
does right now.


No, sorry, that can't be right! If you click on a combo box to select
at item of the drop down (say) RETURN already does something (it
commits the menu change to the combo box). It can't also be used to
commit the dialog contents as a whole. So it's already used for something
there.

Also dialogs would not process return (perhaps despite appearing
to have focus by the blue bar) unless a text control/combo etc.
was explicitly clicked in (right?), and it would not be possible
to explicitly give a dialog focus if it had no combo boxes or text
controls (e.g was radio buttons, checkboxes etc. only).

Personally I'd rather just ditch all return/escape etc. processing to
that, because it's so obscure as to whether it would work or not.
Just think for a minute about CTRL-W / ALT-F4. You open dialog 1.
You click in a text field. You close it using CTRL-W. You open
dialog 2.  You click on a button. You hit CTRL-W and it closes
your document. Does that sound intuitive? That would be the logical
result of doing dialog key processing only when in a control. I'd
rather have it either ALWAYS work, or NEVER work.


Yes indeed. Noone is arguing return should per-se close the dialog.
The question is whether it should do the same as an OK button
(if present), and whether it should do the same as an Apply
button (if present), or whether it should be passed to the
document. Ditto Escape (w.r.t Cancel and Close).


The default OS GUI guidelines should be followed, which AFAIC are that
return does the default action, the button that is the default button is
highlighted (usually heavy outline) and Esc does the same as Cancel. I
support that. Non-modal dialogs would have the default action to be the
Apply button. They should have no Cancel and so Esc would not close the
dialog.


Currently this doesn't happen (we don't have a default button). We
(obviously) could do.

HOWEVER if you have a default button, aren't people going to expect
it to work if you have just opened the dialog? Or if you click
on the title bar? They aren't going to expect it to work only
if you click on a field first, or (worse) never (as there aren't
any fields to click in).


Would you say the same thing about (say) the tracer?


The tracer should either be non-modal (in which case it has to apply the
trace to the selected object and track the selection change, as does the
colour dialog and other non-modal dialogs such as galleries and bars.)


That's what it currently does.


Or it has to be model.


Sure.


If it's made truly non-modal then I'd suggest the default action would
be 'trace'. Esc should do nothing. The only way to close this dialog
should be Alt-F4 or clicking the close buttons.

(I see the default action button is not highlighted in the Tracer dialog
and thus it has no default action for return, and indeed Return does
nothing, which is OK in this case)


Slightly off-topic (but not much) - There is a case to be
made that every non-modal dialog should be dockable. This is
trivial to do (and might even work well now wxAUI works
well). This will compel us to fix key handling. This would
turn them into "palettes". They could indeed all dock in one
long docking bar and be "rolled up" (this is a little harder,
but not a great deal). Perhaps we could argue that if this
functionality would /not/ be useful, they shouldn't be
non-modal anyway.


Yes I think I agree with this. Non-modal dialog are designed to stick
around and that means it would always be useful to have the docking
option, so they can be kept out of the way.


We could then make them all wxMiniFrames (thin title bar) which would
at least alert people to the fact they don't behave like normal dialogs
in respect of key-presses. The modal ones would stay that way.


Yes I agree. So Combo boxes (and menus in fact) can take focus when
clicked on and not pass back keys that could be classed as confusing.
(so delete would do nothing as you say, but pressing F2 would change
tool selection - although I can't really see why you'd do that while
you're messing with a menu frankly).


I was thinking of something much simpler where one category of
control ALWAYS took ALL keys, and the other NEVER took ANY keys.

Alex