app-proto focus indicator lapse and focus handling. #23
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Start app-proto as of branch
element-serial
as of this writing. Use the mouse to select an assembly from the drop down list. Immediately after this operation, that drop-down menu control has the focus, as you can verify by hitting the up and down arrows; they will cycle through the possible assemblies in that menu. However, there is no on-screen graphical indication as to where the focus is. But there does exist such an indicator, as one can verify by repeatedly hitting the tab button to go to the next control until you get back to that assembly menu control, at which point it will both have focus and be nicely highlighted.In any case, just after the selection of a new assembly, whatever component has focus should be clearly indicated. I am not sure whether it should be that drop-down menu, or the outline, or the graphical view. Seems best to me if using the menu is focus-neutral, i.e. focus should stay on whatever had it just prior to using the dropdown (and remain clearly indicated).
There is one more concern with focus indication. The highlight for focus indication is much more vivid on the graphical view of the assembly if you get there by tabbing than it is if you get there by clicking on the view. They should be the same.
One more item to mention, not worth working on at the moment: once clicks on the graphical view do something, there is the question of whether clicking on an unfocused graphical view merely focuses it, or whether that click also has the usual behavior it would have on an already-focused graphical view. I feel pretty strongly it should be the latter. Otherwise, the interface becomes too "clicky". (In fact, I kind of like focus-follows-mouse, i.e., just mousing over the graphical view should focus it. But I feel significantly less strongly about that point than the one that "focusing" clicks should also have their usual behavior -- I bring it up only because focus-follow-mouse implies that clicks will have their usual behavior, since the view became focused as soon as your mouse entered it to do the click).