Community
Participate
Working Groups
Created attachment 96532 [details] Apply to org.eclipse.gef An edit part's focus state is not updated properly which may result in no visible focus feedback in the viewer. This problem will surface if GEF's SelectionManager is used. The SelectionManager's focusPart is not updated properly, and consequently, each edit part's focus state is not also. Looks like null is always passed to the graphical viewer's setFocus method. This results in the selection manager's setFocus method to not update the current and new editparts' focus states. See patch. With this fix, my edit part's setFocus method gets called.
This could be related to bug 143046.
Created attachment 97021 [details] Shapes example with fix Here is an example of the shapes diagram with the fix. Three ellipse figures are selected but one is in focus. Compared, visually, to what happens without the fix, the focus border is not drawn.
Created attachment 97022 [details] Logic Sample - Circuit in focus
Other notes: The multiple selection behaviour would be consistent with say selecting multiple files in the Project Explorer. (While holding down the shift key, select different files). There will always be one with a focus border. In the Logic diagram, try tabbing between the logic diagram with the palette. The focus will change, but the selection remains.
We cannot simply apply this change to GEF as it will affect all clients. For example, GMF does not want the extra focus "dotted lines" as shown in the example screenshots. GMF already indicates the selected shape with black connections anchors. Then again, so does the GEF shapes example so I am not sure why this fix is even needed.
(In reply to comment #5) > We cannot simply apply this change to GEF as it will affect all clients. > > For example, GMF does not want the extra focus "dotted lines" as shown in the > example screenshots. GMF already indicates the selected shape with black > connections anchors. Then again, so does the GEF shapes example so I am not > sure why this fix is even needed. > I take this back, when using the keyboard, GMF does indeed show focus feedback on the shapes. Focus feedback does not appear when selecting with the mouse. I will test some more when I get a chance to see which editors hit this line of code.
> I take this back, when using the keyboard, GMF does indeed show focus feedback > on the shapes. Focus feedback does not appear when selecting with the mouse. That's it exactly. SelectEditPartTracker does *not* set focus on the editpart when it is selected with the mouse, for the reason you mentioned (the black handles already indicate the last part selected). Similarly, when de-selecting with the mouse (CTRL+Click), it would be annoying to see a focus rectangle left behind after a mouse gesture. The KeyHandler on the other hand always sets focus to be displayed because the user performed the change using CTRL+SPACE or CTRL+ARROW (for navigating without selecting). These differences in behavior are intended.
Here are some examples, to compare behaviour: 1. Eclipse Color palette. (Window->Preferences->General->Appearance->Colors and Fonts) If you mouse click/select one of the basic color squares, you see the focus border as well as the selection rectangle. Using the arrow keys actually changes the focus...you have to press the spacebar to select the color. 2. In Windows, if you select any of your desktop icons, you don't see a focus border. 3. In Windows Explorer, if you view as icons or as list or details, you do see the focus border around the text. (And if you do a CTRL-left click, the selection goes away, but the focus border remains). 4. IE's tabs have focus borders. So, it's debatable whether the focus border should be there or not, it depends on the application/client. In my example, I need my edit parts to have their focus states updated, so that showFocus will be called. Here are some details of what I'm seeing: I'm extending SelectionEditPolicy, so when my editpart gets selected, its setFocus is called: protected void addSelectionListener() { selectionListener = new EditPartListener.Stub() { public void selectedStateChanged(EditPart part) { setSelectedState(part.getSelected()); --> setFocus(part.hasFocus()); } }; getHost().addEditPartListener(selectionListener); } but because the editpart's focus state never gets updated (hasFocus always returns false), the showFocus method (which I override) never gets called from here: protected void setFocus(boolean value) { if (focus == value) return; <-- it'll always return here focus = value; if (focus) --> showFocus(); else hideFocus(); } I think clients can decide whether to draw the focus border or not in this showFocus method. Yes, unfortunately, it will affect a lot of clients that use or extend this edit policy and use the SelectionManager. In particular, the shapes, logic, and flow samples use the Resizable and NonResizable edit policies, where there is already existing code in place to draw the focusBorder.
> but because the editpart's focus state never gets updated (hasFocus always > returns false), the showFocus method (which I override) never gets called from > here: That shouldn't be the case. Try selecting your part with the mouse and pressing CTRL+SPACE. It should have focus at that point. Does it not?
We do not have enough to go on here without breaking clients, so resolving as WONTFIX. Keith, you will have to reopen and continue the discussion if you feel strongly otherwise.
