Community
Participate
Working Groups
Papyrus-RT product build #510. The Code Snippet View forgets which tab was active for some kind of element whenever the selection is changed to a different kind. If I edited the Guard of a Transition and select another transition, the Guard tab is still active. That is good. However, if I change the selection to an element that has no code snippets, say an Initial pseudostate, and then select a transition, even the same transition that I was working with before I selected the pseudostate, the active tab reverts to Effect. Also, if I edit the Guard of a Trigger and then select a Transition, I would expect the Guard tab still to be active because transitions have guards, but the view changes to the Effect tab. Finally, as a related case to the second paragraph above, if I edit the Guard of a Transition, then select a State, obviously the Guard tab is not applicable, so some State-appropriate tab is active. But then on selecting a Transition again, even the same transition from before, the Effect tab is activated. So, in general, I think the default tab activation should be something like: * the most recently activated tab that is applicable to the selection * otherwise, the first tab available for the selection (if any) where tabs that edit the same conceptual detail of different elements (e.g., Transition Guard and Trigger Guard) are treated as the "same tab."
I was planning on providing similar feedback, when initially testing the code snippet view but have waited to do so. Good to have a bug for tracking this. When comparing Christian's proposal with how it works in the legacy tooling it partly works like this in the legacy tooling. At least this about "the most recently activated tab that is applicable for the selection". In the legacy tooling it seem to work like this. When it comes to "otherwise, the first tab available for the selection (if any)" seem to prioritize tabs which do have code, e.g. if a transition only have a guard then that tab is activated (if no specific tab have been activated prior to this). So I think that we could make the selection to prioritize a tab which have some code in it, i.e. have a bold label. Apart from that the legacy tooling seem to have a behavior which I personally not sure that I like, and that is that it also reorders the tabs based on if they have code in them or not, e.g for the case when a transition only have guard but no effect, then the order of the tabs is "Guard" tab first and "Effect" tab second. Normally the tab order is "Effect" first and "Guard" second. Personally I think that I prefer the fixed order. On the other hand, this about prioritizing tabs with code and activate those, then becomes always activating the first tab! And then we are back as Christian had formulated the rule! :) We should also keep in mind Bug 513275 which will add support for choice points, where we should get one tab for the guard for each of the outgoing transitions. In that scenario, maybe it makes sense to order the tabs based on if they have guard or not (then the "false" transition, without guard will always be sorted last). So maybe the sorting makes sense for that situation at least. For the other elements the order maybe should be fixed ("Effect", "Guard for transtion and "Entry", "Exit" for state).
Thanks, Peter. That's a good amendment: in the case that no other tab had previously been activated, then a tab that has code should be activated on the assumption that perhaps the user will want to see it. I agree that a fixed tab order is best.
(In reply to Christian W. Damus from comment #2) > Thanks, Peter. That's a good amendment: in the case that no other tab had > previously been activated, then a tab that has code should be activated on > the assumption that perhaps the user will want to see it. > > I agree that a fixed tab order is best. Thanks for the input. +1 for keeping fixed tab order.
Too late for 0.9 unless the fix has already been developed. If it has, then let me know and we can move back to 0.9.
(In reply to Simon Redding from comment #4) > Too late for 0.9 unless the fix has already been developed. If it has, then > let me know and we can move back to 0.9. No fix available for this yet.
This should be already fixed as part of other code snippet view bugs.
I tested this in the latest Papyrus-RT build (#595) and from what I can tell it is only partly resolved. Yes, the aspect that the most recently activated tab that is applicable to the selection seem to be in place. But not this about what we concluded in Comment 2, and let tabs that have code take precedence over tabs that don't contain code. Quote from Comment 2: "in the case that no other tab had previously been activated, then a tab that has code should be activated on the assumption that perhaps the user will want to see it." I can't see that this behavior have been implemented.
(In reply to Peter Cigehn from comment #7) > I tested this in the latest Papyrus-RT build (#595) and from what I can tell > it is only partly resolved. Yes, the aspect that the most recently activated > tab that is applicable to the selection seem to be in place. > > But not this about what we concluded in Comment 2, and let tabs that have > code take precedence over tabs that don't contain code. > > Quote from Comment 2: > > "in the case that no other tab had previously been activated, then a tab > that has code should be activated on the assumption that perhaps the user > will want to see it." > > I can't see that this behavior have been implemented. Currently, code snippet view(csv) remembers selection for the same type of element. For example, if you select a guard tab for transition then that selection is remembered for any transitions selected afterwards. That is how property tab works. I can make change so that the tab with the code is selected by default before user makes any tab selection. However as soon as user clicks on a specific tab then this behaviour will not apply for the subsequent selection for the same type of element. If you want to remember tab choice for each element selected not the type of element then we need to track all the elements that we have selected and follow these elements if they are removed or closed and so on. I am not really sure we need that. So I suggest that we keep the tab selection for the same type of element and implement the behaviour to select the tab with code by default until user makes a specific tab selection. Let me know if you would be satisfied with this.
Possibly more work to do.
(In reply to Young-Soo Roh from comment #8) > (In reply to Peter Cigehn from comment #7) > > I tested this in the latest Papyrus-RT build (#595) and from what I can tell > > it is only partly resolved. Yes, the aspect that the most recently activated > > tab that is applicable to the selection seem to be in place. > > > > But not this about what we concluded in Comment 2, and let tabs that have > > code take precedence over tabs that don't contain code. > > > > Quote from Comment 2: > > > > "in the case that no other tab had previously been activated, then a tab > > that has code should be activated on the assumption that perhaps the user > > will want to see it." > > > > I can't see that this behavior have been implemented. > > Currently, code snippet view(csv) remembers selection for the same type of > element. For example, if you select a guard tab for transition then that > selection is remembered for any transitions selected afterwards. That is how > property tab works. I can make change so that the tab with the code is > selected by default before user makes any tab selection. However as soon as > user clicks on a specific tab then this behaviour will not apply for the > subsequent selection for the same type of element. If you want to remember > tab choice for each element selected not the type of element then we need to > track all the elements that we have selected and follow these elements if > they are removed or closed and so on. I am not really sure we need that. > > So I suggest that we keep the tab selection for the same type of element and > implement the behaviour to select the tab with code by default until user > makes a specific tab selection. Let me know if you would be satisfied with > this. The behavior should be as Christian stated, i.e. as long as the user have not made an explicit choice of tab, i.e. the user have never explicitly switched to another tab, then the tab with code should be activated and shown as the default tab. As soon as the user have made an explicit choice for a specific tab, then it is that tab that should be the default for that element type. There is no need to track this be element instance, just track it be per element type. Take the scenario where the user opens a model with the purpose of just "browsing around" checking code snippets and clicks on different states and transitions. Then the tab with code should be the default shown tab so that the user don't have to switch tabs at all (unless there is code in multiple tabs and the user needs to make an explicit choice). Take the most common case where you only have a bunch of transitions with effect code (no guard), and some choice points with outgoing transitions with only guards (and no effect). Then the user should be able to select these transitions, and the effect respectively guard tab that contains code should be selected automatically without user having to make the switch. And yes, this switching will be "disabled" as soon as the user makes an explicit switch, since the explicit selection now overrides the automatic switching to the tab with code. I have checked, and this seem to be the same behavior in the legacy tooling (apart from that the legacy tooling also have the slightly confusing re-ordering of tabs, which we already have decided to keep the fixed order).
New Gerrit change created: https://git.eclipse.org/r/96345
Gerrit change https://git.eclipse.org/r/96345 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=429defebbbe5b70a0080ae6c2a081ba6fff8ae56
Peter already verified that the fix was working so Charles can close this bug.
Closed on Young-Soo's advice in comment 13
