Community
Participate
Working Groups
When creating a new RT state machine, an initial state, a transition and a first state is created by default and displayed. However, the layout of these elements is not perfect, users have to move them usually. (Created from Bug 481607 comment 17)
Assigned to Future until we have a better understanding of the effort required and impact on users.
I suggest that this one is planned for 1.0. Since we currently have a regression on the Oxygen track that the initial layout of the state-machine diagram has become even worse than for Neon, we need to do something related to the initial layout. I suggest to let this existing bug track this aspect. See for example last part of Bug 514322 Comment 74 for more information about this. This regression *could* thus be related to ELK, or the fact that we have disabled ELK in the tester setup. One aspect to consider related to ELK is that ELK is still in incubation, and I guess it is unsure if we can depend on ELK if Papyrus-RT itself is about leave incubation.
Created attachment 268657 [details] Screen shot showing the current default layout using tester setup The screen shot show the current layout when using the tester setup (ELK disabled) running build #729 on Windows 7. As can be seen the position is way too far up causing a scroll bar to appear. The transition is now even visible. When trying to move the elements down, you cannot even select the initial pseudo-state. To be able to select you need to use the special marquee tool on the palette to be able to select, and then switch to the ordinary selection tool to be able to move. So this is just a complete pain right now. One "workaround" is to close the diagram, and to reopen it, in which case everything seem to be shifted down slightly making it possible to adjust position used the ordinary selection/move tool. Another aspect is that the transition from the initial pseudostate to the first state is connected on the "wrong side" of the pseudostate causing for example the effect cog wheel to end up on top of the initial pseudostate itself, which makes it "invisible". So currently the default layout is a real mess and something needs to be done for the 1.0 release.
(In reply to Peter Cigehn from comment #3) > Created attachment 268657 [details] > Screen shot showing the current default layout using tester setup Do you have the snap-to-grid enabled by default for new diagrams? I turned it off in my preferences and I turn it off in all diagrams. (I recommend that our RCP product also disable this for new workspaces in the plugin_customization.ini)
(In reply to Christian W. Damus from comment #4) > (In reply to Peter Cigehn from comment #3) > > Created attachment 268657 [details] > > Screen shot showing the current default layout using tester setup > > Do you have the snap-to-grid enabled by default for new diagrams? I turned > it off in my preferences and I turn it off in all diagrams. (I recommend > that our RCP product also disable this for new workspaces in the > plugin_customization.ini) Yes, I have the default settings that comes with changes in base Papyrus on the Oxygen track. I have not made any changes to the new settings for the grid and snap preferences. I have just assumed that this change in base Papyrus has been done for a good reason and that it should be kept "as-is".
Created attachment 268661 [details] Screen shot showing the default layout without snap to grid The layout is slightly better with the snap to grid switched off. No scroll bar, and the transition is connected (partly) on the right side of the initial pseudostate. And it is possible to select and move the initial pseudostate without having to use the marguee tool. The layout is kind of similar to what it was on Neon, but in the other direction (vertical instead of horizontal).
Created attachment 268662 [details] Screen shot showing the layout as it was in Papyrus-RT 0.9 based on Neon Just for comparison here is the default layout as it was on the Neon track, i.e. it had an vertical, instead of horizontal layout.
(In reply to Christian W. Damus from comment #4) > (I recommend > that our RCP product also disable this for new workspaces in the > plugin_customization.ini) If we decide to switch it off in the RCP, then we must ensure that same in the end-user and tester Oomph setup files as well I assume. But it still feels a bit dangerous for anyone that want to use snap-to-grid and get that kind of layout as in Attachment 268657 [details].
*** Bug 517805 has been marked as a duplicate of this bug. ***
