Community
Participate
Working Groups
Papyrus-RT shall support that model elements are selected for editing in model explorer directly after creation. This is means that we need to support for this in base Papyrus. This Bugzilla is mainly for tracking that work in Papyrus, and possibly tracking any additional Papyrus-RT/UML-RT specific needs, e.g. if some additional customization is needed on top of existing customizations in Papyrus-RT, e.g. to support the renaming of protocol messages (see also Bug 480403).
Confirmed by Peter via email. Moving to new.
Nice to have. Does not gate MVP1
(In reply to Simon Redding from comment #2) > Nice to have. Does not gate MVP1 I am not sure that I agree here. If I would pick *one* usability/user experience thing that annoys me the most with Papyrus/Papyrus-RT compared to the legacy tooling, it is the lack of this feature. Having to press F2 (and even for new users to know about it) each time you have created a new model element in the model explorer, or having to move the mouse down to the properties view, double click on the name, and start renaming is just plain annoying and time consuming (no wonder that people want textual notations when it so cumbersome to create new model elements in the model explorer with a user defined name). Since work is already progressing on the Papyrus side, see Bug 497289, where something has already been merged into the Oxygen branch (although I have not gotten it to work so I cannot judge what it really is supposed to do), I would really like this to be included on the Neon branch (see Bug 497289 Comment 6) as well and thus possibly also into Papyrus-RT. Personally I think that this is rather important for 1.0 of Papyrus-RT.
Moved to 0.9 and will be fixed for 1.0
Now when Bug 476629 partly have been fixed (there are still some issues with the initialization of the embedded editor requiring a manual work around, see Bug 476629 Comment 8 and Bug 497289 Comment 18) I tested this a bit in the context of Papyrus-RT for the elements that can be created using the UML-RT new child menu. For the "ordinary" UML elements created via the UML-RT new child menu it works as expected, e.g. Class, Attribute, Operation, Enumeration, EnumerationLiteral and Package. But for the UML-RT specific elements it does not work: Capsule, Capsule Part, Port, Protocol. Fascinating enough, it do seem to work for Protocol Messages though! What can be seen in several of these cases, is that the name seem to "flash" for a brief moment, but the embedded editor does not seem to "stick" so that you actually can start edit the name.
Now when an initial fix for Bug 502269 have been provided for the Neon branch of Papyrus, the inline editing directly after creation works as expected also in a new fresh workspace. The inconsistency regarding the UML-RT specific elements as mentioned in Comment 5 becomes really evident though, so we should look into why it does not work for these elements (Capsule, Protocol, Capsule Part and Port) and probably compare with *why* it works for Protocol Message (which is kind of surprising considering that it does not work for the other UML-RT specific elements).
(In reply to Peter Cigehn from comment #6) > Now when an initial fix for Bug 502269 have been provided for the Neon > branch of Papyrus, the inline editing directly after creation works as > expected also in a new fresh workspace. The inconsistency regarding the > UML-RT specific elements as mentioned in Comment 5 becomes really evident > though, so we should look into why it does not work for these elements > (Capsule, Protocol, Capsule Part and Port) and probably compare with *why* > it works for Protocol Message (which is kind of surprising considering that > it does not work for the other UML-RT specific elements). Initial observation is that it looks like all other non working types have RT stereotype applied but protocol message does not have stereotype.
Raised new bug bug#509653 for base Papyrus.
Since the change for Bug 509653 have been merged, I have now tested this in the latest build of Papyrus-RT, based on the latest build of Papyrus. And the four identified cases (Capsule, Protocol, Port and Capsule Part) do indeed now work, and the direct edit works okay when creating these elements in the model explorer. It do however exposes the same kind of issue as already identified by Bug 509268 related to the direct editor for parameters. For some scenarios, e.g. when creating a port typed by a system protocol in Papyrus-RT, now makes an error marker to appear on the created port (including that a comment element is created owned by the port) due to that the reference to the system protocol cannot be resolved. I suggest that we put this bug into resolved fixed (unless there are some other known aspects left to be resolved, e.g. unit tests), and write a separate bug for the direct editor of ports (and possibly capsule parts) similar to Bug 509268 for the case of protocol message parameters. We have already fixed a similar issue that existed with the direct editor for transitions, tracked by Bug 476365, where the direct editor for a transition was replaced by a simple name editor. I suggest that we initially do the same also for ports and capsule parts, and then if needed, introduce a more advanced direct editor which possibly can edit the type at a later point in time. The simple name editor should preferably be in place already for 0.9 to avoid the bad user experience when creating ports based on system protocols.
New Gerrit change created: https://git.eclipse.org/r/92239
New Gerrit change created: https://git.eclipse.org/r/92769
Gerrit change https://git.eclipse.org/r/92239 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=b9136c9c0d9dd88b20036b5e3db0a1c1e28d2a5c
Moving back to resolved so that we can indicate that a verification has been made.
Verified to be fixed in the latest Papyrus-RT build. The direct editor is activated in the model explorer after creating all kinds of model elements, including the UML-RT specific ones (Capsule, Protocol, Port and Capsule Part). There are issues identified for capsule part, and especially ports, as tracked by Bug 513500, Bug 513060, and Bug 512809. Improvement for protocol message parameters are tracked by Bug 509268 to avoid issues when selecting types from the primitive types library, in similar ways as for ports typed by system protocols from the run-time model library. Putting into verified fixed.
Closing as verified fixed.
