Community
Participate
Working Groups
When setting the focus on a diagram editor, we get SubDiagramDecorator.refresh() called for each editPart. And this SubDiagramDecorator.refresh() by calling DialectManager.INSTANCE.getRepresentations() use a ECrossReferenceAdapter. This bugzilla has been created to check why this refresh is useful and if useful to find a smarter mean to refresh this decorator. FYI this decorator is used to indicate that from the concerned editPart, there exists some representations to which we could navigate.
"This bugzilla has been created to check why this refresh is useful " Here are the scenario it is supposed to cover. * You have diag 1 which is opened * Either using the model content view or another tool, you ends up creating diag 2 and diag 2 is supposed to be navigable from diag1. * When you get back to the diag 1 editor the setFocus will trigger the refresh and you'll see the decorator. The lack of mechanisms to "listen changes in the list of things which are accessible using the navigation" led to this solution/hack.
Created attachment 253141 [details] Example project In attachement an example project to show that SubDiagramDecoratorProvider.refreshEditParts() call in DDiagramEditorImpl.setFocus() is not usefull when representations addition/removal. In fact EditPart are registered on DiagramEventBroker to be notified of representations addition/removal by DiagramElementEditPartOperation.activate(this); call, more specifically DiagramElementEditPartOperation.addNavigateDecoratorRefresher(). For this last handleNotificationEvent() of EditPart should call refresh of its navigate decorator only when there is a notification about ADD/REMOVE/ADD_MANY/REMOVE_MANY on DRepresentationContainer.ownedDRepresentations reference and when the new/oldValue(s) have the current semantic element as target.
(In reply to Esteban DUGUEPEROUX from comment #2) > Created attachment 253141 [details] > Example project > > In attachement an example project to show that > SubDiagramDecoratorProvider.refreshEditParts() call in > DDiagramEditorImpl.setFocus() is not usefull when representations > addition/removal. > In fact EditPart are registered on DiagramEventBroker to be notified of > representations addition/removal by > DiagramElementEditPartOperation.activate(this); call, more specifically > DiagramElementEditPartOperation.addNavigateDecoratorRefresher(). > For this last handleNotificationEvent() of EditPart should call refresh of > its navigate decorator only when there is a notification about > ADD/REMOVE/ADD_MANY/REMOVE_MANY on > DRepresentationContainer.ownedDRepresentations reference and when the > new/oldValue(s) have the current semantic element as target. This code bugs me a little. Looks like the editpart listen to the dviews which are hosted by the session *when the editpart gets activated*. So what happens when a new DView is created ? Let's say the user, after creating the first diagram, enables another viewpoint to create the second one, this listener will fail, isn't it ?
New Gerrit change created: https://git.eclipse.org/r/47120
New Gerrit change created: https://git.eclipse.org/r/47121
New Gerrit change created: https://git.eclipse.org/r/47133
Cédric : Yes by DRepresentation addition/removal I also include first creation through a DView. On EditPart activation there is also EditPartAuthorityListener which refresh the SubDiagramDecorator will it is not always needed. I will rename this bugzilla title to manage more generally useless SubDiagramDecorator refresh.
Here a summary of org.eclipse.gmf.runtime.diagram.ui.services.decorator.IDecorator implementations : AbstractDecorator (from GMF) -> AbstractSiriusDecorator (from Sirius) -> EditModeDecorator (from Sirius) : is to display lock decoration, should be refreshed only on lock status changes through EditPartAuthorityListener. BookmarkDecorator (from GMF) : is to display bookmark, see http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-28.htm , should be refreshed on markers changes of type IBookmark.TYPE. DescribedDecorator (from Sirius) : to display decoration from odesign, should be refreshed on DDiagramElement.decorations feature changes. - StatusDecorator (from Sirius) : to display validation severity decorators with their tooltip. Should be refreshed only on markers change through a workspace listener. - SubDiagramDecorator (from Sirius) : to display navigate decorator, should be refreshed only on DRepresentation addition/removal and perhaps on viewpoint activation/deactivation. This decorator needs only to know if there are representations whose target is same as semantic element of the current EditPart. - UnresolvedViewDecorator (from GMF) : to display a decorator when a GMF View no more reference an element through its View.element feature. These decorators should perhaps also be refreshed on EditPart activation when the current state make decorators display needed. Or perhaps that could be done in IDecorator.activate(). The fact to refresh all decorators through DecorationEditPolicy.refresh() is not efficient. We should make decorator refresh specific to each ones.
New Gerrit change created: https://git.eclipse.org/r/47257
Gerrit change https://git.eclipse.org/r/47120 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=48b97eb172523e763440623d1535e21b0700876c
Leaving in 3.1 for now because the work has already started, but with reduced priority: it's a "nice to have", but not a "must do". From the current patches in Gerrit, it looks like this can be done without breaking APIs (the current patches add some new ones though).
New Gerrit change created: https://git.eclipse.org/r/52696 WARNING: this patchset contains 1066 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
New Gerrit change created: https://git.eclipse.org/r/52695
Gerrit change https://git.eclipse.org/r/47121 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=2dc52ae13d57f104df833504a373997db959d91a
Gerrit change https://git.eclipse.org/r/47257 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=cbe45abb0dfc20dbe6b17969dabbb95058bf056c
The above commit (cbe45a) has finally be reverted as it causes regressions on some automatic tests of an other product. It will require further analysis before being pushed again.
Moving out of the 4.0 scope for now, along with all the other issues which were there "by default". This does not mean some of these will not be re-integrated at some point, but for now these issues are not part of the roadmap for 4.0. If you feel strongly about this removal from 4.0 and/or are ready to sponsor the corresponding work, feel free to comment.
