Community
Participate
Working Groups
Link with Editor in Model Explorer does not work properly. When having it enabled and selecting an element in a diagram, this element does not get selected/highlighted in Model Explorer. When selecting e.g an attribute in the diagram the class get expanded and the attribute get displayed in Model Explorer, but it does not get highlighted. When selecting an element in Model Explorer the saame element does not get selected/highlighted in the diagram.
The ModelExplorer#reveal method depends on the Guava API > 10.0.1. 3 different versions of Guava are available in Eclipse. Because the dependency is not strict, Papyrus uses Guava 11.0.0, in which some deprecated APIs have been removed. The ModelExplorer depends on them. Fix in 79dcffad1cf3a3df5949eb6befad9847c9082c1f: The ModelExplorer now has an explicit dependency to Guava 10.0.1 (Excluding newer versions) As this is a runtime dependency issue, I still need to verify if the issue is properly fixed after an update. I don't close the bug yet
Bug 419591 is another symptom of the same issue. The whole model explorer selection display is broken. There is a different issue for the diagram (When selecting an element in the ModelExplorer, it isn't highlighted in the diagram). It doesn't seem to be related.
> There is a different issue for the diagram (When selecting an element in the ModelExplorer, it isn't highlighted in the diagram). It doesn't seem to be related. This part of the bug is a change in the behavior of the Eclipse Platform in Luna (Eclipse 4.4). The IWorkbenchPage used to delegate the "Adapter" resolution to the Active Part. This is not the case anymore (The concrete implementation of the WorkbenchPage doesn't implement IAdaptable anymore) The implementation of the Papyrus service resolution helper has been changed accordingly. Fixed in 8679ab48de78be75e277aa0c18c17ac6595e2404, pushed to master (This only fixes the synchronization from ModelExplorer to Diagram).
I tracked down this issue to the creation of TreeViewerFocusCellManager in the CustomCommonViewer class, that creates the TreeViewer for the Model Explorer. When this class is used, the link with editor is broken. Hoewever, this class is required to activate the direct editing via keyboard since the keyboard event does not contain a location where the ViewerCell can be calculated from. Since the default activation key F2 can not be used there because it triggers the rename element action I think it is a good idea to activate the direct editor via double click - this would fix this problem, too.
Created attachment 237494 [details] Proposed patch to open direct editing on double click in Model Explorer
*** Bug 419591 has been marked as a duplicate of this bug. ***
andreas, thanks for the patch and the problem analysis. I prefer not to use a double click, since it also opens the tree element. The patch pushed with commit cca01ab216701a80935ed147df7c950862271616 enables editing via F3 and also shift+F2 (as F2 is already used for renaming). I don't know, which of the options we want to keep, but since this bug is blocking two others, I want to get something pushed rather quickly. I think it would be good, if renaming would later-on also open an in-tree editor instead of a pop-up. Toni, can you please re-check?
I just downloaded the latest nightly Luna 1.0.0.v201402091226. Not sure exactly what you ask me to check wrt the discussion above on F2, click, shift and so on, so I checked the "link with editor" problem on our network models + some other models and... Halleluja, it works again! :) It works both when clicking in a diagram and getting the element focused in on and highlighted in the Model Explorer, and when clicking on an element in Model Explorer and getting it highlighted in an open diagram. But... It doesn't work for elements in a diagram which have been dragged-and-dropped from an imported model. This is however a slightly different and separate issue, so this bug can be closed. :) But I think there should be a separate bugzilla opened for this new issue on highlighting elements also in imported models, and that new bugzilla report should also cover testing on fragmented models.
It's true that the link is not working for imported elements. I agree that this is a different issue (Camille, is there already a bug on this - if not, can you please create one). With regard to the xtext integration, I pushed commit 937aa8afbdc6acf396f04c67ad752c78f59026f4: The xtext editor is now opened with the standard F2 key, i.e. the rename popup window will not open for elements handled by xtext. In the moment, this is the case for Properties only. When the xtext integration will cover more elements, the filter condition needs to be adjusted in the RenameNamedElementsHandler. I will close this bug and handle successive xtext integration steps in the context of bug 315231
See Bug 360092: [Model Explorer] revealSemanticElement doesn't work with imported package It might be fixed by either Bug 426360 or the refactoring of resources management in Papyrus in Bug 406234 (or any other resource-management-related bug)
*** Bug 405572 has been marked as a duplicate of this bug. ***
*** Bug 428537 has been marked as a duplicate of this bug. ***
