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

Re: [XaraXtreme-dev] Galleries and focus handling

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.


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 think we should fix this properly so ALL dialogs behave the same way,
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).


(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?

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


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

Alex