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

RE: [XaraXtreme-dev] Galleries and focus handling



> 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