Community
Participate
Working Groups
Created attachment 266990 [details] Screen shot showing examples of entry and exit code decorators in legacy tooling Currently if you add entry or exit code to a state, the standard base Papyrus and UML annotation is used, which uses ordinary text inside the state shape itself (at least it is shown directly after creation, closing and opening the diagram removes the entry/exit code markers completely). A decorator that also can show inherited and redefined entry and exit code needs to be introduced. The attached screen shot shows the entry and exit code decorators in the legacy tooling. As can be seen, those decorators does not make any distinction between redefined and locally added entry/exit code, both are shown with a filled arrow head. Inherited (but not redefined) is shown with a hollow arrow head. To be consistent with what has been proposed as part of Bug 510323 it should be considered if a decorator that makes it clear if the entry/exit code has been redefined or not (to distinguish it from locally added entry/exit code). Another aspect to consider is whether it is possible to have a decorator which you can hover above to make a tool-tip appear, to align with the guard and effect decorator on the transition.
Add release note and then move to future.
Moving to future
(In reply to Charles Rivet from comment #2) > Moving to future If this is moved to future, then please consider if fixes are needed for the current label based decorators. To be honest, the current label-based decorators for entry and exit code works really bad. I would probably had written lots of bugs related to these issues, but I have disregarded from all these issues since I knew that this bug was in the pipe for 1.0. Should we start looking into what is crucial to get fixed for 1.0 with the current label-based approach? Or should we just indicate in the release notes for 1.0 that the visualization of entry/exit code on states is limited and have lots of issues?
(In reply to Peter Cigehn from comment #3) > (In reply to Charles Rivet from comment #2) > > Moving to future > > If this is moved to future, then please consider if fixes are needed for the > current label based decorators. To be honest, the current label-based > decorators for entry and exit code works really bad. I would probably had > written lots of bugs related to these issues, but I have disregarded from > all these issues since I knew that this bug was in the pipe for 1.0. > > Should we start looking into what is crucial to get fixed for 1.0 with the > current label-based approach? Or should we just indicate in the release > notes for 1.0 that the visualization of entry/exit code on states is limited > and have lots of issues? For this particular bug, we would need to understand your belief that, as you state it, “the current label-based decorators for entry and exit code works really bad” and a what would be the "lots of bugs related to these issues"
(In reply to Charles Rivet from comment #4) > For this particular bug, we would need to understand your belief that, as > you state it, “the current label-based decorators for entry and exit code > works really bad” and a what would be the "lots of bugs related to these > issues" When testing the current behavior it can be concluded: * The issue mentioned in Comment 0 regarding entry/exit code marker being removed when closing and reopening the diagram have improved and the markers still remains. * There are refresh issues where the markers does not get updated or get "cut off" with ... and you need to close and reopen the diagram to get it to refresh (pressing F5 does not work to get this to refresh). This can be seen in inheritance scenarios where adding entry/exit code in superclass does not get reflected in the subclass respectively when adding entry/exit when it already have exit/entry, where the second added code snippet gets its marker "cut off" with a ... So apart from being really "long and bulky", e.g. with the superfluous OpaqueBehavior included in the label which requires the state to be manually resized to fit this very long and bulky label, there are still some issues (apart from the lack of support for inheritance as already indicated in Comment 0 showing inherited/redefined/excluded entry/exit code, and possible hover support showing the code snippet in a tool-tip as supported for the effect and guard code for a transition).
Just my two cents here as an educator :-). Having a notation close to the UML standard may make life easier for people who want to teach UML-RT to students that just learned about UML state machines. The current text-based decorators use "/entry OpaqueBehaviour name", which is somewhat odd as according to the spec it should probably be "entry/name" (without that odd OpaqueBehaviour). I would perhaps suggest that appearance options are used to allow people to switch between: * a text presentation (perhaps with the option to avoid that OpaqueBehaviour?) more in line with UML (perhaps using "ientry"/"rentry" for inherited entry, redefined entry?), and * a graphical presentation. I do like the icons and the idea of a tooltip showing the code snippets, but I'm not sure how the tooltip would handle very long code snippets. Perhaps the tooltip should be limited to the name + first X characters of the snippet?
(In reply to Antonio Garcia-Dominguez from comment #6) > * a graphical presentation. I do like the icons and the idea of a tooltip > showing the code snippets, but I'm not sure how the tooltip would handle > very long code snippets. Perhaps the tooltip should be limited to the name + > first X characters of the snippet? The tool-tip that shows the effect and guard code for a transitions cuts off at 20 lines of code (see discussion in Bug 510411 related to this, including a screen shot). If you have longer code snippets, then those are best inspected with the Code Snippet View anyway. I assume that if/when a corresponding tool-tip is added for entry respectively exit code, then the same cut-off principle should apply (especially if we share the same implementation for showing the tool-tip).
(In reply to Peter Cigehn from comment #7) > (In reply to Antonio Garcia-Dominguez from comment #6) > > * a graphical presentation. I do like the icons and the idea of a tooltip > > showing the code snippets, but I'm not sure how the tooltip would handle > > very long code snippets. Perhaps the tooltip should be limited to the name + > > first X characters of the snippet? > > The tool-tip that shows the effect and guard code for a transitions cuts off > at 20 lines of code (see discussion in Bug 510411 related to this, including > a screen shot). If you have longer code snippets, then those are best > inspected with the Code Snippet View anyway. I assume that if/when a > corresponding tool-tip is added for entry respectively exit code, then the > same cut-off principle should apply (especially if we share the same > implementation for showing the tool-tip). +1. That looks good to me!
