Summary: | Handling of Focus and Selection should be made more consistent. | ||
---|---|---|---|
Product: | [Tools] GEF | Reporter: | Alexander Nyßen <nyssen> |
Component: | GEF-Legacy GEF (MVC) | Assignee: | gef-inbox <gef-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | hudsonr |
Version: | 3.6.1 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Alexander Nyßen
2010-12-10 16:04:35 EST
You've missed a few details about the current (at least intended) behavior. The goals were to only set focus when the keyboard was being used instead of the mouse. Rendering focus is distracting otherwise, for example, when CTRL+Clicking on something w/ the mouse to take it out of a multi-selection. Even when the keyboard is used, I think setting focus is avoided when simply navigating around (so, changing the only selected part). Editparts are notified of focus when they should visually display focus, not when they have the implied focus. (In reply to comment #1) > You've missed a few details about the current (at least intended) behavior. The > goals were to only set focus when the keyboard was being used instead of the > mouse. Rendering focus is distracting otherwise, for example, when > CTRL+Clicking on something w/ the mouse to take it out of a multi-selection. > Yes, I thought that this was the intended behavior (because setFocus is directly "forwarded" to the edit policies). However, the current behavior does not fully correspond to this policy. I.e. if you move the keyboard to an unselected edit part, then use CTRL + mouse click to append it to the current selection, the edit parts continues to show focus, while the mouse was used for interaction. Corresponding to the intended policy it think it would be consistent if the edit part looses focus in such a situation. That's what I subsume under option b). Here my point is to at least make the current behavior consistent to that policy. > Even when the keyboard is used, I think setting focus is avoided when simply > navigating around (so, changing the only selected part). > Correct, focus is only moved on if CTRL is pressed when navigating. > Editparts are notified of focus when they should visually display focus, not > when they have the implied focus. And that's what I address with option a). I think it would be more consistent, easier to understand for clients, and also more flexible to use setFocus() to actually notify edit parts about receiving/loosing focus rather than for just the graphical bits (I think that could be decided by the edit policies). This way, clients that always want to show the focus additional to the selection (independent of the selection) could also achieve this, while the current behavior w.r.t. to displaying focus feedback could be created by simply preventing edit policies to show focus feedback in case their host is also primary selected. Using setFocus() this way would also allow that a primary selected edit part could display gain/loss of focus in case the graphical viewer itself gains or losses focus. > (independent of the selection) could also achieve this, while the current
> behavior w.r.t. to displaying focus feedback could be created by simply
> preventing edit policies to show focus feedback in case their host is also
> primary selected.
If the user is moving focus around using CTRL+ARROW, focus should not "disappear" when it passes over the current primary selection.
(In reply to comment #3) > > (independent of the selection) could also achieve this, while the current > > behavior w.r.t. to displaying focus feedback could be created by simply > > preventing edit policies to show focus feedback in case their host is also > > primary selected. > > If the user is moving focus around using CTRL+ARROW, focus should not > "disappear" when it passes over the current primary selection. Well, with option a) such a decision could be left to the clients (i.e. to the edit policies), where - I agree - the default behavior should be to show focus in such a case. Handling of focus and selection is also inconsistent within RulerViewer, where focus is also shown to indicate selection. I think we should come up with a consistent handling of focus and selection in all viewers. Maybe it would be best (in difference to what I sketched in a) or b)) to handle them as two orthogonal concepts that can be handled independently. That implies that focus should always be explicitly assigned and indicated, independent of the selection state (in case a user uses the mouse to select, he of course also assigns the focus part). This would be the simplest and most straight-forward algorithm. |