Bugzilla – Full Text Bug Listing
| Summary: | [Tooling] Improve the behavior of the port creation tool on palette in capsule structure diagram | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus-rt | Reporter: | Peter Cigehn <peter.cigehn> |
| Component: | tool | Assignee: | Christian Damus <give.a.damus> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | Celine.janssens, charles, papyrus-bugs |
| Version: | 0.8.0 | ||
| Target Milestone: | 0.8.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=491543 https://git.eclipse.org/r/70515 https://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=7c4ced9f8175e2dde279e85416317efa1fddd54b |
||
| Whiteboard: | |||
| Bug Depends on: | 491473, 491478, 491542 | ||
| Bug Blocks: | |||
|
Description
Peter Cigehn
We also need to support the creation of a port on capsule part (or actually the contour/border of a capsule part). This should then create an external behavior port of the capsule used to type that capsule part. This is also related to the new child menu which allows you to right click on a capsule part in the model explorer, and then create a port. The same shall of course be possible to achieve using drag-and-drop. Currently in the latest Papyrus-RT build, only a stop-sign is shown when hovering and selecting a capsule part as a drop target (as well as anywhere inside the capsule as indicated by bullet 1) in Comment 0). Hello Peter, As this task is quite old from now on, could you tell me if the bullet 4,5 and 7 are still relevant ? I don't reproduce them. Again in order to simplify the tracking of those tasks, I suggest to split this into subtasks. Is it ok for you ? (In reply to Celine Janssens from comment #2) > As this task is quite old from now on, could you tell me if the bullet 4,5 > and 7 are still relevant ? I don't reproduce them. Yes, bullet 4 is still applicable. When you get up the dialog where you either can select an existing protocol (using the ... button) or create a new protocol (using the + button), then when pressing the + button you still get up the dialog about selecting a parent/container element. It is perfectly okay to always create the new protocol in the same parent/container as the current capsule. The same goes for bullet 5, the dialog for creating the actual protocol still has a title "Create a new null". Bullet 7 though seem to have been fixed. The name clashing do no longer occur, but the created protocol gets a new unique name with the next available number suffix. But in general I would like to have a rather different work flow, especially when you consider Bug 477729. In general I would like to improve the work flow for both port creation and capsule part creation to move the choice of selecting an existing capsule/protocol or create a new capsule/protocol to be made using a popup menu. This popup menu can the easily be extended to include more menu choices, as described in Bug 477729. > > Again in order to simplify the tracking of those tasks, I suggest to split > this into subtasks. > > Is it ok for you ? Considering that I really would prefer another work flow, I am not sure about splitting. But sure, if this change of work flow will not be done, then we probably need to split it as you say. But if we do not change, then I do not understand how Bug 477729 can be fit in in a nice and easy way for the user to select any of the system protocols. Please also see Bug 477819 for exactly this discussion. To clarify, I think that bullet 1 in Comment 0, is rather fundamental (disregarding the discussion about a different workflow after the the "drop" action). Since it is not possible to "drop" the port to create inside the capsule (you get the stop sign then), you cannot create an internal behavior port. The only possible kind of port to create using the port tool on the palette is currently to create the external behavior port (on the border of the capsule), which is bit too limited. (In reply to Peter Cigehn from comment #4) > To clarify, I think that bullet 1 in Comment 0, is rather fundamental > (disregarding the discussion about a different workflow after the the "drop" > action). Since it is not possible to "drop" the port to create inside the > capsule (you get the stop sign then), you cannot create an internal behavior > port. The only possible kind of port to create using the port tool on the > palette is currently to create the external behavior port (on the border of > the capsule), which is bit too limited. I made this specific issue into its own Bugzilla, see Bug 490859. None of the tooling in question will be usable at all as until the fix for bug 491473 is merged. Christian, will you take a look at Bug 477819 at the same time? They basically are in need of the same kind of improvements, so I guess it makes sense to look at both of these at the same time. (In reply to Peter Cigehn from comment #7) > Christian, will you take a look at Bug 477819 at the same time? They > basically are in need of the same kind of improvements, so I guess it makes > sense to look at both of these at the same time. Yup. Note that I'm leaving the dialog in place that asks for selection or creation of the protocol/capsule to use as the type of the port/part. I do that because this seems to be the Papyrus standard editing paradigm, and I'd rather not change that just in this case. Also, because I think I can make it work better than it currently does. I have changes pending that do skip the selection of the container in the case of creating a new protocol/capsule, so that makes the editing experience already considerably more efficient. Also pending is a fix to the cancel button not being available, and to cancel (either by that button or forcibly closing the window) proceeding with creation of the port/part anyways. Oh, and also undo not undoing the port/part creation but only the creation/setting of its protocol/capsule type. The more difficult problem is disabling the OK button until a protocol/capsule for the port/part is selected or created. That is because the EditionDialog [sic] used by the RuntimeValuesAdvice offers no provision at all for input validation to conditionally enable the OK button. To add that would require several additions to the Papyrus API, which is now past its API Freeze for the Neon release. So, I would have to implement this locally in Papyrus-RT project with a custom advice implementation using a custom dialog. And that warrants breaking that work item out into a separate enhancement bugzilla so that this one (and bug 477819) can be resolved by the fixes I outlined above. New Gerrit change created: https://git.eclipse.org/r/70515 Gerrit change https://git.eclipse.org/r/70515 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=7c4ced9f8175e2dde279e85416317efa1fddd54b I've tested this merged patch-set in the latest Papyrus-RT build. The dialog is now indeed cancelable, and when canceling (or closing) the dialog nothing gets created (port respectively capsule part). The other changes I verified in the context of Bug 477819 Comment 12. With the resolution of the related bug 491543 and other patches merged previously, the issues logged in this bug are now resolved. Notwithstanding the original item #1 which has been extracted into its own bug 490859. And I guess there never was an item #6. :-) Verified in the latest Papyrus-RT build. The work flow has been improved a lot when using the port creation tool on the palette. So this Bugzilla can be put into verified fixed. There are however a few related things to be done, tracked by other Bugzillas: Create internal behavior in Bug 490859. Create port on capsule part in Bug 492368. Creation of SAP based on system protocols, Bug 477729. There is also some aspects happening part of this work flow when using the new child menu to create a port, where any capsule parts get resized when the port gets created (it also impact the "Auto Size" function which calculates a smaller size whenever there is a port added from the new child menu). I will look into this an write some Bugzilla for this. This is also related to the incorrect handling of the behavior adornment when the port is placed exactly in the upper right corner (one can also see some graphical glitches when this happens). So I guess that is at least two other Bugzillas related to this. Closing as verified fixed. |