Difference between revisions of "Integrate GMF runtime with Mylyn task focused UI"
|(3 intermediate revisions by one other user not shown)|
|Line 1:||Line 1:|
This project is part of [[Google Summer of Code 2010|Google Summer of Code 2010]]. Source code can be found [http://code.google.com/a/eclipselabs.org/p/mylyn-gmf-ui/source/checkout here]. First edited by [http://www.
This project is part of [[Google Summer of Code 2010|Google Summer of Code 2010]]. Source code can be found [http://code.google.com/a/eclipselabs.org/p/mylyn-gmf-ui/source/checkout here]. First edited by [http://www...// Yongming Luo].
== Abstract ==
== Abstract ==
Latest revision as of 05:02, 14 March 2013
Similar functionality and other modeling support are being actively developed as part of Mylyn/Modeling_Bridge.
Mylyn is a task management framework. By using it, the workspace can have different "snapshots" for different tasks. When one task is selected, only the related objects (files, opened windows, etc.) are shown in the workspace. That is so called "task focused UI". On the other hand, the GMF runtime provides a common graphical notation model for every Eclipse Modeler. By combining the two techniques together, a mylyn bridge can be developed, showing the graphical elements in editor depending on the relevance of the current task. This project can also be an example to show how to integrate GMF techniques to a real project.
The generated GMF editor used in this project is EcoreTools Editor. The development procedure is divided into two parts:
- A mylyn bridge that fits for the generated GMF editor
- A context listener that listens to the context and changes the representation of the diagrams in the editor
Three classes need to be extended when implementing a mylyn bridge: AbstractUserInteractionMonitor, AbstractContextStructureBridge and AbstractContextUiBridge. It's a good idea to start with the AbstractUserInteractionMonitor, for the monitor does not need any other classes to support it, and you can directly see the result from the current context without implementing the other classes. The next step is to implement the StructureBridge and UIBridge. The main idea of the bridge is to create a mapping between objects and Strings(handles). When the mapping is done, Mylyn can deal with the Strings without worrying about the real objects. During implementation, I found it's convenient to learn from the existing implementations (e.g. Ant Bridge). For EcoreTools Diagram Editor, a lot of files are generated within the package, which is a little bit confused. I found EcoreNavigatorContentProvider very useful to take a look at.
Context Listener listens to the changes of the current context and do actions according to it. This blog post I wrote includes an example of implementing a mylyn context listener and showing the context by zest framework. The idea is to extend the AbstractContextListener class, while all the events are passed through contextChanged() method. In my implementation, the context listener is added to the workspace when the plug-in is started (EcoreToolsUIBridgePlugin.start()), and removed when the plug-in is stopped. Whenever there is an event, the editor will be refreshed and all the diagrams in the editor will change their representations if it's needed (EcoreToolsUtil.refreshEditor()).
- A patch for GMF framework which can generate a mylyn bridge automatically would be interesting.