Community
Participate
Working Groups
To make it easy to view and edit effect and guard code for transitions, as well as all other code snippets in form of opaque behavior (and possibly opaque expressions and opaque actions) a dedicated view should be introduced. Another approach could be to have a separate tab in the properties view for editing these code snippets, but one major drawback with this and one major benefit of a separate view is that the code snippet view should follow the selection of any model element, both the selection of a model element in the model explorer, in any diagram, including the selection of a referenced model element in the properties view itself, e.g. in tables with owned/child elements of another element. Thus it is probably best from a usability perspective to provide a separate view, instead of a separate tab in the properties view. If the selected model element provides multiple code snippets, e.g. when selecting a transition it both have a code snippet for the effect code as well as guard code, then the different possible code snippets shall be provided as different tabs labeled with the relevant code snippet. This should of course be extendible for all different kinds of model elements that can have code snippets, including supporting code snippets in the RTCppProperties profile where code snippets can be provided for lots of different aspects of the generated code. Here are som initial examples, and not exhaustive list, of code snippets with focus specifically on state machines that shall be supported for the code snippet editor view: * State: Entry, Exit * Transition: Effect, Guard * Trigger: Guard * Choice Point: Guards for each of the outgoing transitions This can then be extended with editing operations of capsule and passive classes. One major responsibility of the code snippet view will be the creation of any opaque behaviors, and administration of the language/body lists, i.e. creating an opaque behavior if needed and then set the language and provide editing of the related body. Related to setting the language is the default language framework, see Bug 487187. An integration with CDT for syntax coloring and content assist shall also be considered for the code snippet editor, but initially it is probably okay to limit editing to plain text.
Even though it was not mentioned explicitly, it shall be noted that the use of scrollbars must allow large amounts of code to be added in the code snippet view. This is to ensure that any issues similar to the one reported in Bug 484704 is avoided for the new code snippet view.
hi Peter, Currently properties tab follows any selection made in the model explorer as well as in the diagram if that is the one of the reason why a new view is required. Having separate view requires new UMLRT perspective to include this and it requires a lot more effort to set up properties view framework because you need to build it from the scratch. I think having a separate tab in the existing properties view would be best suited at this time in my opinion. Do you think it would be ok to have a separate tab for the code snippet? or do you really need to have a separate view? We can create multiple tabs for different kind of code snippet but that could be too much for the properties tab. (In reply to Peter Cigehn from comment #0) > To make it easy to view and edit effect and guard code for transitions, as > well as all other code snippets in form of opaque behavior (and possibly > opaque expressions and opaque actions) a dedicated view should be introduced. > > Another approach could be to have a separate tab in the properties view for > editing these code snippets, but one major drawback with this and one major > benefit of a separate view is that the code snippet view should follow the > selection of any model element, both the selection of a model element in the > model explorer, in any diagram, including the selection of a referenced > model element in the properties view itself, e.g. in tables with owned/child > elements of another element. > > Thus it is probably best from a usability perspective to provide a separate > view, instead of a separate tab in the properties view. > > If the selected model element provides multiple code snippets, e.g. when > selecting a transition it both have a code snippet for the effect code as > well as guard code, then the different possible code snippets shall be > provided as different tabs labeled with the relevant code snippet. This > should of course be extendible for all different kinds of model elements > that can have code snippets, including supporting code snippets in the > RTCppProperties profile where code snippets can be provided for lots of > different aspects of the generated code. > > Here are som initial examples, and not exhaustive list, of code snippets > with focus specifically on state machines that shall be supported for the > code snippet editor view: > > * State: Entry, Exit > * Transition: Effect, Guard > * Trigger: Guard > * Choice Point: Guards for each of the outgoing transitions > > This can then be extended with editing operations of capsule and passive > classes. > > One major responsibility of the code snippet view will be the creation of > any opaque behaviors, and administration of the language/body lists, i.e. > creating an opaque behavior if needed and then set the language and provide > editing of the related body. Related to setting the language is the default > language framework, see Bug 487187. > > An integration with CDT for syntax coloring and content assist shall also be > considered for the code snippet editor, but initially it is probably okay to > limit editing to plain text.
(In reply to Young-Soo Roh from comment #2) > Currently properties tab follows any selection made in the model explorer as > well as in the diagram if that is the one of the reason why a new view is > required. Having separate view requires new UMLRT perspective to include > this and it requires a lot more effort to set up properties view framework > because you need to build it from the scratch. I think having a separate tab > in the existing properties view would be best suited at this time in my > opinion. > > Do you think it would be ok to have a separate tab for the code snippet? or > do you really need to have a separate view? > > We can create multiple tabs for different kind of code snippet but that > could be too much for the properties tab. It is pretty fundamental that the code snippet view is a separate view, since it shall follow the selection both in the model explorer, in the diagram, but also selections made in the properties view itself. Take the example when you shall edit the guard code for a trigger, in which case the code snippet view shall follow the selection in the trigger table in the properties view for transition. Apart from that it is rather painful to have to switch tabs back-and-forth in the properties view, if you want to both see the properties on the UML-RT tab, at the same time as you edit/browse the code snippets in the model. This is also rather similar to the new documentation view that has been introduced rather recently in base Papyrus, where you have a new (separate) view for editing and viewing the documentation/comment of a given model element. So yes, it is absolutely fundamental that this is a separate view in the same way as it is in the legacy tooling. This should really be aligned with legacy tooling as it has been discussed so many times, i.e. unless we really know (based on experience) that the legacy tooling have a less optimal solution, we should try to align withe legacy tooling to ensure that legacy users have the same kind of user experience. I will provide some additional screen shots so that you get a better feeling for how the code snippet view looks like in the legacy tooling (the best would of course be if you tried the legacy tooling yourself). I am not fully sure that the best solution is to align with the properties view and its vertical tabs. The code snippet view in the legacy tooling have horizontal tabs at the bottom (similar to how the diagram editor in Papyrus have the tabs for different diagrams). If we get into timing constraints, then move this back to the 1.0 release if we have a hard time getting this in place for 0.9. I really don't want to have some "work around" for this just to get it into 0.9. Then it is better to get "the right" solution for 1.0 instead. And yes, with the introduction of the code snippet view, we also need to introduce a specific Papyrus-RT perspective. That has been anticipated from the beginning, so that should not stop us from introducing a new view.
Created attachment 266312 [details] Screen shots from legacy tooling showing different examples of selected elements The attached PFD contains a number of examples with different selected elements. As already listed in Comment 0 they are State, Transition, Trigger, Choice Point. But I think that we also should support Junction Point (same principle as for Choice Point) and also Operations of capsules/classes. The aspect related to providing tabs for the code snippets that can be provided via the RtCppProperties profile, needs to be aligned with the tooling support for the general editing of those. This is not included in the scope of this bug, but it is only mentioned for preparing the code snippet view to be extendible with additional tabs corresponding to code snippets that can be provided via the RtCppProperties profile.
Hi Peter, Thanks for the info. New view can be implemented similar to what is in the RSARTE but will require two weeks of effort for text based code view. (In reply to Peter Cigehn from comment #4) > Created attachment 266312 [details] > Screen shots from legacy tooling showing different examples of selected > elements > > The attached PFD contains a number of examples with different selected > elements. As already listed in Comment 0 they are State, Transition, > Trigger, Choice Point. But I think that we also should support Junction > Point (same principle as for Choice Point) and also Operations of > capsules/classes. The aspect related to providing tabs for the code snippets > that can be provided via the RtCppProperties profile, needs to be aligned > with the tooling support for the general editing of those. This is not > included in the scope of this bug, but it is only mentioned for preparing > the code snippet view to be extendible with additional tabs corresponding to > code snippets that can be provided via the RtCppProperties profile.
Moving to 1.0
(In reply to Peter Cigehn from comment #4) > But I think that we also should support Junction > Point (same principle as for Choice Point) I must correct myself here. Compared to the legacy tooling, we have actually introduced a constraint in the UML-RT profile document, which states that a junction point can have at most one outgoing transition, and that transition must not have a guard condition. This means that what I initially wrote in Comment 0 is correct. We shall *not* support editing the guard for (the single) outgoing transition of a junction point. Please disregard from that example from the legacy tooling with a junction points selected, in the attached PDF file. I had forgotten about this limitation that we introduced in the UML-RT profile document, compared to what the legacy tooling supports. Sorry for any confusion this might cause.
(In reply to Peter Cigehn from comment #7) > (In reply to Peter Cigehn from comment #4) > > But I think that we also should support Junction > > Point (same principle as for Choice Point) > > I must correct myself here. Compared to the legacy tooling, we have actually > introduced a constraint in the UML-RT profile document, which states that a > junction point can have at most one outgoing transition, and that transition > must not have a guard condition. This means that what I initially wrote in > Comment 0 is correct. We shall *not* support editing the guard for (the > single) outgoing transition of a junction point. Please disregard from that > example from the legacy tooling with a junction points selected, in the > attached PDF file. > > I had forgotten about this limitation that we introduced in the UML-RT > profile document, compared to what the legacy tooling supports. Sorry for > any confusion this might cause. How will model import handle this when found in legacy models?
(In reply to Charles Rivet from comment #8) > How will model import handle this when found in legacy models? See Bug 494284 Comment 11 also. One of the reasons why this constraint was introduced in the UML-RT profile document in the first place (you were actually part of the discussion and voted for it), was that it was considered to be rather seldom used, and thus the constraint could be introduced. So I would say that we don't do anything specific about it, and let any model that for some reason have used it, to get a validation warning (and possibly a code-generation warning).
Please review follow gerrit so that the code snippet view will be in for 0.9. https://git.eclipse.org/r/#/c/91656/
(In reply to Young-Soo Roh from comment #10) > Please review follow gerrit so that the code snippet view will be in for 0.9. > > https://git.eclipse.org/r/#/c/91656/ Okay, when was it decided that the code snippet view was going to be included in 0.9? Isn't it a bit too late to decide that now? It is still planned for 1.0, and there are lots of other stuff that needs to be tested for 0.9. Personally I am not sure that I have the time to *also* review and test the code snippet view this late. What about everything that is related to inheritance? We have spent quite some time testing the scenarios for redefining action code *without* the code-snippet view. Now that needs to be re-tested *with* the code-snippet view. Can these kinds of decision be made more clear and open, so that we can prepare for it.
(In reply to Peter Cigehn from comment #11) > (In reply to Young-Soo Roh from comment #10) > > Please review follow gerrit so that the code snippet view will be in for 0.9. > > > > https://git.eclipse.org/r/#/c/91656/ > > Okay, when was it decided that the code snippet view was going to be > included in 0.9? Isn't it a bit too late to decide that now? It is still > planned for 1.0, and there are lots of other stuff that needs to be tested > for 0.9. Personally I am not sure that I have the time to *also* review and > test the code snippet view this late. What about everything that is related > to inheritance? We have spent quite some time testing the scenarios for > redefining action code *without* the code-snippet view. Now that needs to be > re-tested *with* the code-snippet view. > > Can these kinds of decision be made more clear and open, so that we can > prepare for it. Hi Peter, it's ok if you are busy with other stuff. I will have to wait if someone has time to review. If it is not reviewed for 0.9 then it will go in 1.0. Thanks.
(In reply to Young-Soo Roh from comment #12) > (In reply to Peter Cigehn from comment #11) > > (In reply to Young-Soo Roh from comment #10) > > > Please review follow gerrit so that the code snippet view will be in for 0.9. > > > > > > https://git.eclipse.org/r/#/c/91656/ > > > > Okay, when was it decided that the code snippet view was going to be > > included in 0.9? Isn't it a bit too late to decide that now? It is still > > planned for 1.0, and there are lots of other stuff that needs to be tested > > for 0.9. Personally I am not sure that I have the time to *also* review and > > test the code snippet view this late. What about everything that is related > > to inheritance? We have spent quite some time testing the scenarios for > > redefining action code *without* the code-snippet view. Now that needs to be > > re-tested *with* the code-snippet view. > > > > Can these kinds of decision be made more clear and open, so that we can > > prepare for it. > > Hi Peter, it's ok if you are busy with other stuff. I will have to wait if > someone has time to review. If it is not reviewed for 0.9 then it will go in > 1.0. > Thanks. Just to double-check: How much of the code-snippet view have so far considered inheritance and redefining inherited action code from a super-class? Have that been considered in the implementation done so far? Just for my understanding if the code-snippet view even is ready to be included in 0.9.
(In reply to Peter Cigehn from comment #13) > (In reply to Young-Soo Roh from comment #12) > > (In reply to Peter Cigehn from comment #11) > > > (In reply to Young-Soo Roh from comment #10) > > > > Please review follow gerrit so that the code snippet view will be in for 0.9. > > > > > > > > https://git.eclipse.org/r/#/c/91656/ > > > > > > Okay, when was it decided that the code snippet view was going to be > > > included in 0.9? Isn't it a bit too late to decide that now? It is still > > > planned for 1.0, and there are lots of other stuff that needs to be tested > > > for 0.9. Personally I am not sure that I have the time to *also* review and > > > test the code snippet view this late. What about everything that is related > > > to inheritance? We have spent quite some time testing the scenarios for > > > redefining action code *without* the code-snippet view. Now that needs to be > > > re-tested *with* the code-snippet view. > > > > > > Can these kinds of decision be made more clear and open, so that we can > > > prepare for it. > > > > Hi Peter, it's ok if you are busy with other stuff. I will have to wait if > > someone has time to review. If it is not reviewed for 0.9 then it will go in > > 1.0. > > Thanks. > > Just to double-check: How much of the code-snippet view have so far > considered inheritance and redefining inherited action code from a > super-class? Have that been considered in the implementation done so far? > Just for my understanding if the code-snippet view even is ready to be > included in 0.9. I've tested code snippet view with inherited and redefined situation. So the view will show inherited contents and as soon as user make change to the contents then it will create a redefined element to store new code.
I have spend some time testing the proposed Gerrit change, and the general feeling is that this looks good and should hopefully be possible to merge and get included in 0.9. I think that it would be really beneficial if we had this already in 0.9 release. I have provided some feedback that would be good to get fixed, e.g. the aspect when a model is closed and reopened, which seem to break the code snippet view (both the title and icons on the tabs gets broken).
(In reply to Peter Cigehn from comment #15) > I have spend some time testing the proposed Gerrit change, and the general > feeling is that this looks good and should hopefully be possible to merge > and get included in 0.9. I think that it would be really beneficial if we > had this already in 0.9 release. I have provided some feedback that would be > good to get fixed, e.g. the aspect when a model is closed and reopened, > which seem to break the code snippet view (both the title and icons on the > tabs gets broken). All the issues Peter pointed out should be resolved in the latest gerrit. Trigger table stays same as before except that the guard is no longer editable since code snippet view is there for that reason. I would like to work on any Trigger table enhancement as a separate bug as it would take some time and would not want to hold code snippet view making it to 0.9.
Yes, I think it is good to keep the scope of this bug down to a minimum to get the code snippet view in to 0.9. What is left should be tracked with separate bugs, e.g. the support for selecting a choice point (as described in Comment 0) which is currently not implemented yet Another improvement related to selection is that if a child element, e.g. the entry opaque behavior of a state is selected in the model explorer, then the code snippet view should track it as if the state itself was selected, i.e. the title should indicate the state, and automatically select the relevant tab, i.e. in this case the entry tab shall be selected/activated automatically. This then goes for entry/exit of a state and guard/effect of a transition, guard for a trigger. I suggest that if we decide to get this included in 0.9, that the Gerrit change is merged as soon as possible so that it can be tested as much as possible before the 0.9 release in conjunction with inheritance for example.
Gerrit change https://git.eclipse.org/r/91656 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=80b76f1c962ce43f584449ed6bfd4576797a4afd
Updating target milestone to indicate that this will be included in the 0.9.0 release.
(In reply to Peter Cigehn from comment #17) > Another improvement related to selection is that if a child element, e.g. > the entry opaque behavior of a state is selected in the model explorer, then > the code snippet view should track it as if the state itself was selected, > i.e. the title should indicate the state, and automatically select the > relevant tab, i.e. in this case the entry tab shall be selected/activated > automatically. This then goes for entry/exit of a state and guard/effect of > a transition, guard for a trigger. I wrote Bug 513387 to track this improvement.
Verified to be fixed in the latest Papyrus-RT build. There now exist a code snippet view which can be used for editing the entry and exit code of states, effect and guard for a transition, and guard for a trigger. Editing the guard for outgoing transitions of a choice point is not implemented yet, and tracked separately with Bug 513275. The code snippet view is also able to redefine and inherited action code in subclass in an inheritance scenario.
Closing as verified fixed.
