Hi,
I think we need to step back a bit to the basics regarding the work flows when using the code snippet view when editing code snippets in a state-machine. Let us disregard from the aspects of inheritance, redefinition and finally this aspect of exclusion for a moment.
First of all I would like to highlight a few important aspects when it comes to the visual cues we give to the user regarding the existence of any code snippets, i.e. we both have the cog-wheel decorator on the transition (and eventually we will have similar decorators for entry and exit of a state as tracked by
bug 512699). Apart from that we also have the label on the relevant tab in the code snippet view itself, i.e. a bold label on the effect/entry/exit tab indicates that it do have some contents, i.e. an opaque behavior do exist in the model and its body is non-empty, i.e. it can very well just contain white-spaces or commented code. The bold label on the tab still gives a clear indication that the code snippet contains *something*. See
bug 494288 and the attachment to that bug for some examples from the legacy tooling.
If I compare with how the legacy tooling works we have the following basic scenario:
1) The user have a state-machine with some transitions with no effect defined, i.e. no cog-wheel decorators and the effect tab in the code snippet view has a non-bold label
2) The user starts typing in some code in the effect tab for a transition. The cog-wheel decorator appears and the bold label on the effect tab now indicates clearly to the user that some effect code snippet now exist for this transition
3) The user realizes that the code was entered wrongly and the user simply uses back-space to "undo" and empty the code snippet.
4) The cog-wheel decorator disappears and the effect tab label goes back to non-bold, both indicating that there now is no effect code defined for the transition.
I think that these two visual cues gives the user are pretty good understanding about what "emptying" the code snippet means, and I personally find this behavior in the legacy tooling to be rather straight-forward and intuitive.
In practice what happened when the user "emptied" the code snippet was that the opaque behavior was removed from the model, which I think is also rather natural. If the opaque behavior was left behind in the model, but only with an empty body, would mean that the user could create lots of "garbage" opaque behaviors without even knowing or understanding. So I think it is rather fundamental to remove the opaque behavior when the code snippet is being "emptied" by the user, as a way of "undoing" code that was entered "incorrectly".
If we then extend this to the inheritance case and look at that. Since the legacy tooling have more limited use of decorators for the locally defined vs. inherited or redefined cases, I am basing this on how we intend this to be work in Papyrus-RT:
1) The user are editing an inherited state-machine with inherited and existing effect code on the transitions.
2) The gog-wheel decorator is washed out indicating existence of some inherited effect code, and the effect tab label shows in bold.
3) The user starts making some changes to the code-snippet, causing it to be redefined. The cog-wheel decorator gets the redefined decorator, which also the cog-wheel icon on the effect tab gets, to clearly indicate that it now is a redefined code snippet.
4) The user now decides to "empty" the code snippet to "remove" the inherited code, comparable to the basic scenario above.
5) When the code snippet becomes empty, the code snippet view should "delete" the opaque behavior, but since it is inherited it is then excluded (this is the same analogy that the same red x delete button is used for both deleting or excluding inherited elements) the opaque behavior is instead exlcuded.
6) The cog-wheel decorator on the transition now gets the excluded decorator, the icon on the effect tab in the code snippet view also gets the excluded decorator, and the effect label is now non-bold to indicate that the code snippet is "empty".
Regarding these aspects of editing the generated code using the CDT editor, we must consider the fact that the code snippet view eventually should have CDT integrated with it (if we want to get on par with what the legacy tooling provides). So the use cases when editing within the context of the complete generated code, will hopefully be a more uncommon case.
I would argue with the reasoning above, that the user intention of "emptying" the code snippet view for inheritance case is pretty natural to see it as an exclusion, given all the visual cues that is given to the user. Sure, we could present a popup asking the user, but to be honest I think that such a dialog would cause more confusion that add clarity. If the user intends the "emptying" the code snippet for further editing in the CDT editor, then I would (as already mentioned) say some TODO comment or at least leaving something left in the code snippet can be used (which is clearly indicated by the bold or non-bold label on the tab in the code snippet view), that then can be further edited in the CDT editor.
Personally I still think that the implicit "delete" (and thus also excluding) of the opaque behavior when the user "empties" the code snippet is a pretty natural gesture using the code snippet view. When the user knows that this is the behavior (which will be pretty obvious when having worked with it for a while), then the user can simply add/leave *something*, like a TODO commment, if the intention is to leave an opaque behavior in the model.
Of course, adding some code to an excluded code snippet using the code snippet view, should automatically switch it back to the redefined state, and the decorator on the cog-wheel should swich back to the redefinition and the label of the effect tab should become bold. So if the user realizes that too much was removed, and thus it ended up in the excluded state, then the user can simply type in a TODO comment to get it back to redefined state for further editing in the CDT editor.
I actually was planning on providing feedback on the code snippet view, regarding the automatic removal of the opaque behavior, already when I verified
bug 494288, but I wanted to include the aspects of inheritance and the then ongoing discussions regarding redefinition and exclusion (which I am now doing).
Does these explanations makes more sense?
/Peter Cigéhn