Community
Participate
Working Groups
The purpose of this task is to enable the integration of XText textual editors inside Papyrus. The global idea (and expected benefit) is to use XText to specify textual grammars for subsets of the UML metamodel (e.g., properties of UML classes, transitions of StateMachines, etc.), and use XText generators to produce textual editors (with all the built-in facilities provided by XText such as syntax coloring, error highlighting, cross-references to elements of the context model, etc.). Then, facilities must be provided to enable the encapsulation of XText generated editors inside Papyrus. The editors must be encapsulated inside popups, and launched after a "direct edit" is performed on a given edit part (of course, the grammar associated with the editor must provide a suitable syntax for the semantic element associated with the edit part). When the popup editor is closed, it must be possible to either withdraw the changes captured by the textual specification, or accept the changes, implying a reconciliation with the context UML model. This task is decomposed into two groups of subtasks. The first group concerns the integration mechanisms per se. It is composed of the following subtasks: 1.1 - Modify the Papyrus extension point DirectEditors, so that popup editors can be used on a direct edit. The modification of the extension point must not imply a direct dependency between Papyrus and XText. 1.2 - Modify GMF generators of papyrus, in order to customize the code of graphical edit parts. The customization must be done in a way that takes into account the modification of the extension point DirectEditors. 1.3 - Implement a generic plugin to be used as a glue between Papyrus and Xtext. The plugin org.eclipse.xtext.gmf.glue (available in the Xtext examples "XText / GMF integration example") can be used as a basis for this plug-in. 1.4 - Provide a developper guide, specyfing how textual editors generated by XText must use the generic "glue" plug-in and contribute to the extension point DirectEditors, so that their integration inside Papyrus becomes straightforward. The second group concerns the implementation of textual editors for subsets of the UML2 metamodel. These editors must follow guidelines defined by the developper guide (1.4), and therefore contribute to the extension point DirectEditors of Papyrus, and use the "glue" plug-in. Textual editors must be provided at least for the following UML metaclasses (the list will be extended when needed): 2.1 - Property 2.2 - Message 2.3 - State 2.4 - Transition Status: 1.1. CLOSED - cf. Rev. Papyrus 1540 1.2. NEW - Assigned to Patrick Tessier. Partially treated in Rev. Papyrus 1544. (Label for links are not taken into account yet).
Previous direct edit dialogs had "ctrl + enter" key binding to close the editor. Is this key binding still relevant ? Is it possible to use "enter" instead ?
Created attachment 173003 [details] Glue plug-in between xtext editors and papyrus
Hi all, I have just posted an attachment concerning a contribution for item 1.3 (generic plug-in to be used as a glue between Papyrus and XText). The file is xtext_gmf_glue.zip. It contains a plug-in called org.eclipse.xtext.gmf.glue, which comes from the "XText/GMF integration example" (available in XText v1.0). I have just adapted it for the specific needs of Papyrus (many thanks to Nirmal Sasidharan and Cedric Dumoulin for their help). This seems to be globally OK, except: - a bug related to restoration of key binding for undo/redo when an xtext editor is closed (i.e., when the diagram editor gets the focus back) - a minor bug related to the deletion of temporary text files (used by popup editors), and update of the model explorer. I think it is however mature enough for commit. I will raise new bugs for the two items mentionned above as soon as it is committed. Cheers, Arnaud
Created attachment 173009 [details] XText-based pop-up editor for UML properties
Hi again, I have posted a new attachment: xtext_uml_property_editor.zip. This is a contribution for item 2.1 (textual editor for properties). It contains three plug-ins, which concern the realization of a textual editor for UML Properties. It has been generated using the XText frameworks, and it encapsulates the contributions for the DirectEdit extension point (modified according to item 1.1). Please note that it uses the plug-in org.eclipse.xtext.gmf.glue (see attachment xtext_gmg_glue.zip). Cheers, Arnaud
(In reply to comment #1) > Previous direct edit dialogs had "ctrl + enter" key binding to close the editor. > Is this key binding still relevant ? Is it possible to use "enter" instead ? Hi Yann, By default, XText editors are multiline editors. The effect of pressing enter is then to insert a CR/NL. In the plug-in org.eclipse.xtext.gmf.glue I have posted, it is however possible to override the key binding for "enter". However, in the general case, multine line editors may be useful (e.g., for specyfing bodies of operations or OCL constraints), and I think it would be better to share a common mechanism for "closing and saving", whatever the editor is (a simple editor for e.g. properties, which does not really need multiline, or complex editor for e.g. bodies of operations).
Currently, in Papyrus xtext editor, we can not specify a name that contains special characters such as: "-", "*", "&". We are constrained by java naming conventions. It would be nice, if we are no longer constrained by java naming conventions.
The xtext integration broke selection in the model explorer, see bug 421392. This has been resolved with 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.
There is a validation issue with the integration. The plugin org.eclipse.papyrus.uml.textedit.property.xtext.ui contains a test constraint that should probably have been removed before committing. This constraint does not execute properly, resulting in the following info message in the validation view upon the first validation: "The constraint "TEST" is disabled. It will not be evaluated."
Removed test constraint with commit 74df1a9a52ad683d15a09cd9db1931c95f11b80a. The commit also includes a better check to disable the rename pop-up: it will not appear, if a direct editor is registered for the selected element (regardless whether xtext or not). Removed package oep.views.modelexplorer.xtext, since the package name was misleading: it was not specific to xtext but to support for editors embedded in the column viewer.
Current status: all text editors have been ported to the new xtext integration, except the stereotype editor. The in-diagram editor works rather well, but the editor in the property view is almost unusable: - No undo/redo - No way to quit the editor without writing the contents back. (esc?) - When other tabs within the property view are selected: updates model and starts validation, even if not dirty (likely focus lost issue). - content assist is not taken into account after selection and triggers validation (likely GTK focus problem)
Most issues with the editor in the property view have been fixed with commit 2a2b368a86e064a82a767aa5498a9949aa93a159 In particular - focus is no longer lost after an element in the editor has been selected. - Simple undo/redo support (no multi-character events) For all editor variants: validation does not popup a progress bar a more. The bar is not useful for validating a small sub-model/expression and caused additional focus issues.
This task can be closed. Subtask Bug 328002 is not blocking (I remove the explicit dependency)
