RE: [XaraXtreme-dev] Galleries and focus handling

["Neil Howe" <NeilH@xxxxxxxx>]

> 
> Charles,
> 
> > So this means you can't give focus to a control that doesn't
absolutely
> > need it. So check boxes etc are example that can't be keyboard
driven.
> 
> Well by default checkboxes CAN be keyboard driven. Every control can.
> Just press TAB to navigate around the controls, then (from memory)
> SPACE sets or unsets the control. It may not work in Xtreme, but it
> is I think the windows style.

Yes we should support keyboard driving where we can.

> 
> > There's one dialog where we get this completely wrong, the align
dialog,
> > where it's not correctly returning focus back to the main app. As a
> > result all your main app key short cuts stops working if you have
> > touched the align dialog - which I, and many moaning customers, have
> > found to be infuriating. i.e. you can change your alignment, but
can't
> > then do a Ctrl-Z to undo it. Clearly that is wrong.
> 
> In Xtreme I think we handle focus as a special case on a per dialog
> basis. I think that's wrong. ALL non-modal dialogs suffer from this
> problem, and they ALL should pass their keypresses back up. There
> is a good argument that modal dialogs should /not/ do this
(obviously).
> I don't think the align dialog is doing anything especially evil.
> Indeed the same problem arises if in Xtreme you have the tracer
> dialog up (also non-modal). I am guess NO dialogs do this by default
> unless "specially modded" and I think the only dialog that is
specially
> modded is the colour picker. Bars are probably done in the base class.

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.

> 
> > It is a difficult issue.  Take the example of sliders. These can
have
> > the concept of having focus, and on Windows and perhaps other OSes
these
> > can then be keyboard driven. But the price for this 'flexibility' is
too
> > high. The last thing you'd want is to adjust a slider, and then find
> > that your arrow keys no longer moves objects on the page or that
Ctrl-Z
> > stops working.
> 
> I think that would actually be reasonable behaviour IF you used the
> keyboard to navigate to the control. IE if you are pressing tab or
> whatever to negotiate around the dialog, as then you'd expect it to
> work. The trouble is that the tab key itself you presumably want to
> pass down to the page under every circumstance I can think of.
> Clearly if you've just clicked on a slider in a non-modal dialog,
> you want the arrow keys to continue to perform their on-page nudge
> function. (Well, I think so anyway).

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.

> 
> > (In the case of mouse wheel events some good apps get this right, in
> > that they do not have the concept of focus, but do intelligently
send
> > the events to the right control, so that scrolling over a slider
will do
> > what you'd expect (adjust the slider, not scroll the page). Scroll
bars
> > are a perfect example, you can and should be able to move over a
scroll
> > bar an wheel to move it without having to click it.
> 
> I had thought that the scrollwheel event was sent to the window under
> the pointer. Surely you don't want key events sent to the window under
> the pointer?

No, only the mouse-wheel events.

> 
>  > (and the galleries
> > are an example where this presently does not work in LX but does
work in
> > Xara Xtreme. i.e. you wheel over a gallery and to scroll the
gallery,
> > wheel over the page and it scrolls the page and no clicks are
> > necessary).
> 
> Scroll bars on galleries are mostly broken because they aren't real
> wxScrollbars. If they were, they would no doubt work. They are kernel
> rendered, don't alter with themes, etc. nasty nasty nasty. That
> particular bug I could fix but I don't see much point in spending
> too much time on them when they should be in for the chop.
> 
> > Presently it's quite easy for galleries. They do not have any need
for
> > focus. They should never have it and it should not be possible to
> > highlight their title bars. The same really should apply to all
> > non-modal dialogs, with the exception where these an editable fields
and
> > they've clicked in it. Galleries have no editable fields, so
shouldn't
> > be a problem. In the case of non-modal dialog that do have fields
then
> > press Enter must return focus back to the main canvas.
> 
> 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.
> 
> This illustrates the folly of doing focus rules by class of window.
They
> should be the same for ALL non-modal dialogs. Essentially you are
> saying CONTROLS other than ones that need it should not be able to
> gain focus. Not WINDOWS other than ones that need it should be able
> to gain focus. If that's right, do it by CONTROL.
> 
> 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?). So it sounds to me like what is happening is
> the windows CAN get focus, but just not controls within them. 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...
> 

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.

> > But it's possible there may be a time where galleries may need focus
> > (e.g. the concept of selected layer) and then we have a major
problem
> > because there are conflicting demands on key short cuts.
> 
> I don't think the layer gallery on Xtreme takes any key shortcuts
> does it? The selected layer cannot (for instance) be moved using
> the arrow keys. Ditto not the selected bitmap or colour. I don't
> see why the layer gallery is a special case here?

It shouldn't need to be a special case.

> 
> >> I don't think galleries themselves are particularly interested in
> >> any keyboard shortcuts, are they?
> >
> > No.
> >
> >> Note that a gallery is really just a dialog. There should be
> >> no special keyboard handling required for galleries that is
> >> different to other dialogs or bars (as far as I can see).
> >> Info bars and long lived dialogs seem to me to present
> >> exactly the same problem space.
> >
> > 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.
> 

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.

Neil