RE: [XaraXtreme-dev] Galleries and focus handling

["Charles Moir" <CharlesM@xxxxxxxx>]

I think there's quite a lot of talking at cross purposes going on. I
have a clear picture in my mind of how it is supposed to work (there are
bugs, such as the Align dialog. The option dialog is an exception - it's
really a modal dialog pretending not to be.) But the galleries, bars,
and colour editor are real non-modal dialogs that, mostly, behave as per
the rules. Phil's summary here is a good pretty succinct summary, that
should be the basis for the rules and coding, and perhaps a developer's
doc.

A few points:
- Yes I'm aware that non-modal controls have a selection. Happens all
over. And yes the traditional way to show this is greyed selection and
IF we need to show focus on top of this the selection becomes much more
prominent.

- We are going against HIG guidelines of probably all OSes, but not in a
serious or bad way. But we've been doing this an *awful* lot longer than
they have and being application developers (not OS guideline writers)
we're front line. OS developers still think it's a good idea to lose the
initial single click on an application windows to give it focus (use a
Mac). That shows how out of touch with reality even the best OS
developers can be.

- We stick to our original guidelines - porting Xara Xtreme and not
inventing new stuff, and thus we do not yet need the concept focus in
controls other than text fields (menus and combos I count as text
fields). We can review the rules once we have a need to keyboard drive
the galleries and improve them. For now we don't, so we do it the Xtreme
way.

Alex said (in a later email)
> For instance, if you have 2 non-modals open, you'd expect that if you
click
> on the title bar of one, that one would go blue, and it would be the
one that
> would close if you pressed return, yes?

No. Because this means just moving, say the colour editor window, would
leave focus in the window and so stop things working in the document
(e.g. Esc should clear the document selection, Return key also does
thing in the main document). So non-modal windows should only show title
bar focus if the caret is placed in an editable field (Xtreme doesn't
always show title bar focus even). Clicking or dragging on a window must
*not* give it, or any control in it, focus.

Alex said;
> Open a non-modal dialog. Do not click in any control. Pressing ESCAPE
closes the
> non-modal dialog (as per your instruction above) and does not clear
the document
> selection, because RETURN and ...

Er, did I say that?  If so that's wrong. As above. If an actual control
had focus (you've edited some values or moved the selection on a menu,
or are dragging a slider) then Esc should cancel that operation, return
control to the main canvas, but not close any dialog.

I treat combo boxes and menus as editable fields. i.e. they can have
focus if the user has clicked on the control, so you can keyboard drive
a combo box menu at this point. Selecting a menu option, like pressing
Enter in a classic text field, would transfer control back to the main
document. See the Xtreme Text tool font menu. You can type on this
(quick short cut to the desired font), and use arrow keys etc, but only
while the menu is up (i.e. it clearly has focus). Pressing tab in an
editable field would transfer focus to another editable field in a
group, but to no other control.

Oh and obviously (I hope) when a control does have focus, then it should
take all keys that makes sense to it, so all the normal edit, arrow,
delete, esc etc should all work in that control and not on the canvas.

Phil rule:
> 7. Mouse wheel events have nothing to do with focus or active windows
> - they are sent to whatever control the mouse is over.

Luke said
> That's a very good point, but probably not in the way you meant it!
It's traditional for X
> applications to also give focus to the control that is under the
mouse, i.e. keys go to it.
> I don't think Gnome allows replicating this behaviour, but I think KDE
might!

What Phil says is right. Scroll wheel over control should send events to
that control, and never when it's not over. It does and should not
transfer focus to anything. This mostly doesn't work in Camelot at the
moment (it was added in the lost years by people who didn't understand).

As Phil says there are tweaks, or more detailed rules to the general
principles he's outlined. E.g. on Linux you can't double click on a
editable field (e.g. Selector Infobar size fields) and type a
replacement. About as annoying as you can get !

So I'd like that we fix this by automatically selecting the whole field
when you click in it. This is general principle that once used, you
never go back. (compare IE to Safari).

As Neil says I think Phil's rules should be the basis of a formal set of
policy rules about how it should work (which is separate from the
implementation details of this policy of course).

Charles



 

> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx 
> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Phil Martin
> Sent: 03 May 2006 09:24
> To: dev@xxxxxxxxxxxxxx
> Subject: Re: [XaraXtreme-dev] Galleries and focus handling
> 
> We have discussed focus handling many, many, MANY times 
> during the development of Camelot!
> 
> A set of rules would make it easier for developers to get to 
> grips with focus handling and I think the basic rules are these:
> 
> 1. A modal dialog with focus obviously consumes all 
> keypresses. The control with focus gets the first chance to 
> use the keypress, then parent windows recursively until the 
> modal dialog itself.
> 
> 2. A modeless control owning the focus uses only the 
> keypresses it needs (see rules 3 & 4) and passes all others 
> on through a chain in this order: control, control parents 
> (recursively), active view, active document, application.
> 
> 3. The assumption is that the active view can usually make 
> better use of keypresses than any modeless control and so the 
> control should use the minimal number of keypresses possible.
> 
> 4. A modeless control owning the focus should only use 
> keypresses if its ownership of the focus is more prominently 
> shown to the user than the selection in the active view. 
> (E.g. flashing caret or boldly shown selected item)
> 
> 5. A modeless control should release focus when it has done 
> its immediate job - it must not hold focus assuming the user 
> will want it again. (?)
> 
> 6. The user must be warned about any destructive operation 
> caused by a keypress in a modeless control even if the 
> operation can be undone.  
> (?)
> 
> Oh, and:
> 7. Mouse wheel events have nothing to do with focus or active windows
> - they are sent to whatever control the mouse is over.
> 
> 
> There's leeway within those rules to fine tune things, such 
> as what happens when a gallery item is selected.
> 
> I think selected gallery items are the biggest problem in focus
> handling: When you're immediately thinking about them you 
> want to be able to use keypresses to handle them - especially 
> Delete! However, if you're thinking about the drawing while a 
> gallery item happens to be selected you don't want a keypress 
> intended for the drawing to be used by the gallery.
> 
> We could make it a user option whether gallery items respond 
> to keypresses or not and, when they do, ensure that their 
> selection is more prominent than the active view by drawing a 
> flashing box around them. But that could be annoying and 
> adding a user option is a cop- out and should only be a last resort.
> 
> BTW, Charles: Note that you /can/ have the concept of 
> different selections at the same time in different windows - 
> many programs do that. The selection in one window remains in 
> place but becomes dimmed or greyed while the focus is in 
> another window and when focus is returned that selection is 
> retained and becomes undimmed. If we did that fear of loss of 
> selection in the active view wouldn't have any impact on the 
> issue of focus handling.
> 
> Phil
> 
> On 3 May 2006, at 01:55, Charles Moir wrote:
> 
> >> I agree. We need a clear policy for all non-modal dialogs.
> >> Otherwise we'll end up with inconsistent behaviour.
> >>
> >>>
> >>> I think we should fix this properly so ALL dialogs behave the same
> >> way,
> >>> yes?
> >>
> >> Yes.
> >
> > And I agree as well. Well for all non-modal dialog. Modal 
> ones are a 
> > different matter entirely.
> >
> >> So just clicking on a slider should not give it focus. Then if the 
> >> slider really does have focus (because the user tabbed to 
> get there) 
> >> then it should respond to the arrow keys.
> >
> > Er, except that Tab is required in the document (moves selection to 
> > next object). So yes it's useful to be able to tab between editable 
> > fields, but I do not agree that it's useful to tab between 
> other types 
> > of controls. Well it can be useful but the price is too high.
> >
> >>> Bzzt. Take the line gallery. It has a line-width field you
> >> can enter a
> >>> value into. If that's not "taking focus" I don't know what is.
> >
> > Yes you're right, so it's treated as any non-modal dialog 
> and returns 
> > focus on Enter. Strangely on Xtreme putting the cursor in this 
> > editable fields does not show the gallery window as having focus. I 
> > suspect that's probably not really correct or necessary.
> >
> >>> However, even that isn't quite all. Presumably RETURN 
> should commit 
> >>> the changes in a non-modal dialog (Should escape cancel 
> it? Should 
> >>> CTRL-W close it?).
> >
> > Yes return should commit and yes Esc should cancel (does on
> > Windows) and
> > no Ctrl-W should not close  it because it should never have 
> focus to 
> > be closed (except when the cursor is in the field). So anyone 
> > expecting Ctrl-W (well actually Alt-F4) to close the dialog 
> they think 
> > has focus will simply result in the main document being 
> closed. That 
> > won't got down well.
> >
> >>> So it sounds to me like what is happening is the windows CAN get 
> >>> focus, but just not controls within them.
> >
> > No, don't see that. Why does a window have or need focus?
> >
> >> And if no
> >>> control has focus within the window, it should pass the
> >> keystroke to
> >>> the page if it doesn't use it (for instance the RETURN case
> >> above). If
> >>> a control DOES have focus, I don't know whether it should pass an 
> >>> unused keystroke on. Hmmm...
> >
> > Yes it absolutely *must* pass all unknown keys on. E.g. the current 
> > galleries stop F-key tool change short cuts working. Can't 
> have that.
> >
> >> Also any gallery that shows a list of items (layer gallery, color 
> >> gallery, font gallery) should really allow the user to 
> scroll through 
> >> the list using the arrow keys. So I think galleries and in general 
> >> ALL non-modal dialogs should take focus. It's just that 
> they pass on 
> >> events that they don't themselves handle.
> >
> > No - this is the exact example I listed earlier. The last 
> thing I want 
> > is arrows key short cuts  NOT moving objects on the canvas. 
>  We have 
> > highlighted gallery items right now, and the program would become 
> > unusable if a range of common key short cuts stopped working. What 
> > would you do with Ctrl-Z - would this undo the last gallery 
> change?  
> > Don't think anyone would ever expect that.
> >
> > And if the gallery did have focus, how do you get it back into the 
> > document without altering the selection?  No, this could not work.
> >
> >>>> Well galleries can presently get focus and that's wrong
> >> because they
> >>>> have no need to ever have focus. And that's what's causing the
> >> current
> >>>> gallery problems I suspect.
> >>>
> >>> They do - see line gallery, name gallery et al.
> >
> > OK we should do just as in Xtreme is at the moment (that has it 90% 
> > right), editable fields should have focus only when clicked 
> in, but at 
> > no other time.
> >
> >> Yes. And we shouldn't have to change the way any gallery 
> window works 
> >> just because we decide to add a text field to it one day.
> >
> > Yes it has to. An editable field, is by definition, what makes a 
> > dialog need focus, briefly for the life of editing that 
> value, and at 
> > no other time.
> >
> > You just need to try and use other software that has traditional 
> > dialog and the traditional focus nightmare (confused users, 
> twice as 
> > many clicks to do anything, lost selection and more) to see why our 
> > tool is so much more productive.
> >
> > OK imagine this scenario. You spend ten minutes carefully 
> selecting 50 
> > objects, and want to adjust something in a gallery, say 
> adjust layer 
> > visibility. Were clicking in the gallery to give focus to 
> the gallery 
> > then a) the canvas selection would have to be cleared (you 
> can't have 
> > the concept of two selections) and b) pressing the Delete key to 
> > delete the selection would what, delete the layer you just 
> clicked on?
> >
> > Or you carefully select 50 objects and want to adjust their size / 
> > transparency / blar so you click a slider to adjust the 
> value, and now 
> > press delete?  Or press arrow key?
> >
> > So it quickly becomes obvious that anything that takes 
> focus away from 
> > the canvas produces severe usability problems.
> >
> > So Xara has it right. Non-modal dialogs can only keep focus if the 
> > user has a blinking caret in the field, and even then all 
> unused key 
> > presses should be passed back. Doing anything like Enter, 
> Esc passes 
> > focus back.
> > Dialog with no editable fields should not be able to have focus at 
> > all.
> > Certainly doing thinks like clicking and dragging on such dialogs 
> > (colour editor layer gallery etc etc) should not leave focus in the 
> > dialog. And certainly just moving a window (gallery, non-modal 
> > dialog), must not leave focus in that window.
> >
> > Charles
> 
>