RE: [XaraXtreme-dev] Galleries and focus handling

["Charles Moir" <CharlesM@xxxxxxxx>]

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.

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

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.

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

I agree.

> We could undo the selection completely when (say) a caret was 
> in a text field). But I don't think that's necessary.

We wouldn't want to do that as it's necessary to see the selection when
operating bars and galleries that apply to that selection.

> We don't take blobs off when another /application/ has the focus.

I know and we should. Not exactly an urgent issue however.

> > Well I don't think it's right that pressing return should 
> close these 
> > dialogs (well it's certainly not right for the colour editor or 
> > galleries).
> 
> I agree in the latter cases. And the colour editor doesn't 
> have an apply/OK button so it wouldn't close. Nor do 
> galleries. I don't think they have cancel buttons either, so 
> escape wouldn't close them.

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.

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

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

> 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.)
Or it has to be model.

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.

> >> 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 key presses 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 (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).

Charles