Bugzilla – Full Text Bug Listing
| Summary: | [note] PapyrusMultiDiagramEditor and GMF abstraction | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Miles Parker <milesparker> |
| Component: | Core | Assignee: | Project Inbox <mdt-papyrus-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | cedric.dumoulin |
| Version: | 0.8.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
I've added a comment in the code, to be sure your message will be taken into account. Comment added in r5554 on the trunk. I cc Cedric who is more aware and reposnsible of this part of the Papyrus archi. I don't thing that Papyrus can be considererd as a generic GMF editor. Papyrus is more a container of editors which can be based on GMF. But Papyrus can also contains others editors that are not GMF aware. So there is no guarantee that the quoted lines of code always return an IDiagramGraphicalViewer. I suspect that if a Table is currently selected, the code return null. Also, there is no guarantee that the code always return the same object on each call, because it depends on the current selection. Normally, this code is not any more necessary in PapyrusMultiDiagramEditor because the adapter mechanism always ask the currently selected editor if it can serve the getAdapter() request. But, we should check that our GMF Editors answer correctly to this request (i.e. they each should have a some code similar to the quoted one). Is your work on Mylyn Modeling Bridge need to be aware of only the current Papyrus nested editor (aka the currently selected diagram), or do you need to be aware of the entire UML model or all diagrams ? If you just need to be aware of the selected diagram, this code could be ok, but it will not work with non GMF diagrams. If you need to be aware of all diagrams or all UML, it may be not the right approach. Thanks. (In reply to comment #3) > I don't thing that Papyrus can be considererd as a generic GMF editor. Papyrus > is more a container of editors which can be based on GMF. But Papyrus can also > contains others editors that are not GMF aware. You mean a given editor instance can be such a thing, sort of similar to the way that say a generated EMF editor can have pages for different viewers? I wasn't aware of that. > So there is no guarantee that the quoted lines of code always return an > IDiagramGraphicalViewer. I suspect that if a Table is currently selected, the > code return null. > Also, there is no guarantee that the code always return the same object on each > call, because it depends on the current selection. OK, thanks for that important clarification. We have a part of our API that takes an edit part and returns whether it can be accepted for diagram focussed management. But that API does assume that for a given editor if it returns true it will return that throughout it's lifecycle. > Normally, this code is not any more necessary in PapyrusMultiDiagramEditor > because the adapter mechanism always ask the currently selected editor if it > can serve the getAdapter() request. But, we should check that our GMF Editors > answer correctly to this request (i.e. they each should have a some code > similar to the quoted one). > > Is your work on Mylyn Modeling Bridge need to be aware of only the current > Papyrus nested editor (aka the currently selected diagram), or do you need to > be aware of the entire UML model or all diagrams ? If you just need to be aware > of the selected diagram, this code could be ok, but it will not work with non > GMF diagrams. If you need to be aware of all diagrams or all UML, it may be not > the right approach. No, we just need to manage whatever current editor / views are being depicted for a given model. We add GMF decorators to those views. That decoration request actually comes from the GMF extension point, so presumably unless the editor could be decorated, we would never make the call. On the other hand, we're managing UI stuff on the Mylyn side so we do need to be notified if the editor is removed, hidden and restored, etc. I never considered the case where and editor part might at some point be a GMF viewer and another point not. :) In a nutshell we just care about the lifecycle of the GMF viewer but in normal usage of course we just assume that that is controlled by the lifecycle of the edit part. That seems to be the only really general way to do it in the workbench. If there is a way to not have to special case this for papyrus that would of course be nice but from what you're saying there might be some added complexities to life-cycle mechanisms, and I don't know if there is even a generic workbench abstraction for this. It seems that the workbench itself makes the assumption that viewer and edit part life-cycles are tightly bound. Maybe this can help you: Papyrus provides a "decorator service". It allows you to ask Papyrus to decorate all specified elements with for example a given icon. It is possible to link that with the GMF mechanism. If you use the decorator service, Papyrus takes in charge to decorate the specified element in all the visible diagrams and also in the model explorer. You don't need to take care about the diagrams life cycles. You just have to says "I want to decorate this UML element with xxx" or "I want to remove the decorator xxx from the element yyy". Check bugs 325610: [General] Papyrus shall enable to set dynamically decoration on elements within a diagram https://bugs.eclipse.org/bugs/show_bug.cgi?id=325610 for more details about the decorator service. (In reply to comment #5) > Maybe this can help you: > Papyrus provides a "decorator service". It allows you to ask Papyrus to > decorate all specified elements with for example a given icon. It is possible > to link that with the GMF mechanism. If you use the decorator service, Papyrus Thanks for the detailed response. But actually, it is limitations of the decorator service that's actually the whole context for needing this. :) Unfortunately, the decorator service doesn't help when the life-cycle for diagram objects is different than the life-cycle for the decorators and we need to be able to manage both. (In this case, we're tracking changes to user interest in various nodes for Mylyn.) Then you do need to know the editor life-cycle so that you know when you no longer need to be tracking changes in related state. The big issue is that we need to be able to find the root edit part for an arbitrary IWorkbenchPart so that we can manage the parts of the context life-cycle that are relevant to the decorators. It's all rather complicated as we've had to work around some other issues as well along the way. For context, this is the relevant code. https://github.com/MilesParker/mylyn.incubator/blob/master/org.eclipse.mylyn.modeling.gmf.ui/src/org/eclipse/mylyn/modeling/gmf/ContextDecoratorProvider.java#L208 private RootEditPart getRootEditPart(IWorkbenchPart editor) { if (getDomainUIBridge().acceptsPart(editor)) { if (editor instanceof DiagramEditor) { DiagramEditor de = (DiagramEditor) editor; return de.getDiagramEditPart().getRoot(); } else { // Seems to be the only way to get Papyrus root edit // part w/o explicit dependencies.. IDiagramGraphicalViewer viewer = (IDiagramGraphicalViewer) editor.getAdapter(IDiagramGraphicalViewer.class); if (viewer != null) { return viewer.getRootEditPart(); } } } return null; } I should mention that one limitation of the GMF decorator service -- I don't know if the Papyrus version is different -- is that it doesn't really give you transparency into the life-cycle of the decorated parts -- it only tell you when they're created, not when they're removed. Also, we're looking for a generic GMF / GEF solution. We really have wanted to avoid building a complete custom implementation for Papyrus, but worst case we could adapt for it without adding dependencies if possible. The current solution does seem to work well for a single diagram situation, but my sense is that there are more complex cases where it would fail. |
This isn't a specific task per se, but I don't know how else to communicate it. re: // TODO : following code is GMF dependent. It should be moved to adapter // Do we really need it? Who use it ? if(adapter == IDiagramGraphicalViewer.class) { IEditorPart activeEditor = getActiveEditor(); if(activeEditor instanceof DiagramEditor) { return ((DiagramEditor)activeEditor).getDiagramGraphicalViewer(); } return null; } I do. :) More generally, for Mylyn Modeling bridge, I'd like to be able to treat Papyrus as much as possible as a generic GMF editor. Currently I'm having to special case a lot of stuff. Thanks for the adapter, don't get rid of it! I'd rather have some way to get directly to the root edit part.