Community
Participate
Working Groups
pressing the SPACE key when no parts are selected, causes the contents editpart to become selected. The contents editpart is implicitly selected, but should never be explicitly selected like this.
This may be a regression due to the SelectionManager added in 3.2, but even if it's not, it's an easy fix most likely.
Alex will investigate.
I've described the problem, but not the symptoms. The symptoms are that many normal activities are mysteriously (because the selection is never visually shown) disallowed if the contents are part of selection. For example, you can't delete, you can't drag/move/reparent. You can't resize, etc. Of course, to see these symptoms you would have to press SPACE, then SHIFT+Select something rather than simple select, which would replace the selection.
Created attachment 54020 [details] proposed patch Hi Randy, It seems that the problem with the "Space" key occurs, because in this case we don't check whether the edit part to be appended to the selection is selectable. GraphicalViewerKeyHandler.processSelect() method doesn't check whether the edit part is selectable and passes the edit part to SelectionManager.appendSelection() method which also doesn't check whether the edit part can be selected. Hence the contents edit part can be selected by pressing "Space" key although it may not be selectable. There are 2 solutions for this issue: 1) place checking code in GraphicalViewerKeyHandler.processSelect() 2) place checking code in SelectionManager The patch implements 2). The code for checking whether edit part is selectable is moved from MarqueeSelectionTool to SelectionManager. Randy, could you please take a look at my reasoning and the attached solution and tell me whether it's acceptable?
There is an exception thrown by the patch code in one of the use cases, so it will be reworked a bit, but I'd like you still to evaluate the idea - the fix plan that I have... is it ok to fix it this way or not...
Created attachment 54086 [details] proposed patch Randy, as per our discussion I'm attaching a new patch. The check for contents edit part is done in GraphicalViewerKeyHandler.processSelect() method. However, perhaps this check should be done in SelectionManager? In the tree viewer (outline view) GMF logic example user can select the diagram's tree item, hence when it's selected SelectionSynchronyzer calls setSelection() on the GraphicalViewer passing DiagramEditPart as one of the edit parts to select. Since, there is no checking done in setSelection method from the SelectionManager, the content edit part becomes selected explicitly... This is why I'm thinking about moving the check on the SelectionManager. What do you think about it?
The patch looks correct but there is no need to also test for the root editpart. It is valid for the contents part to be the "focus" part. But it is never valid for the root to have focus.
Created attachment 54348 [details] patch This is the patch to be committed. (The check for root edit part is removed)
Committed patch to HEAD and R32_Maintenance. Also updated the copyright to indicate change in 2007.
