Community
Participate
Working Groups
Master branch as of commit baeb276 (25 Apr 2016). The capsule structure diagram does not permit creation of ports on capsule-parts: the Port tool shows the no-smoking cursor on a part, and neither protocols cannot be dropped from the Model Explorer onto parts to create ports. This contrasts with the Model Explorer's new-child menu, in which a capsule-part has a "UMLRealTime -> Port" item that creates a port on the capsule type. Either the Model Explorer should not permit creation of ports on parts, or the diagram should (by both palette tool and protocol drop). BTW, this does run into interesting scenarios in which the capsule defining a part is read-only, being modelled in a library resource deployed in a plug-in, for example. In these cases, the creation of a port on the part would have to be disallowed, which can lead to confusion in users because, unlike the case where the part itself is read-only, there is no visual cue to suggest that its type is read-only, so users are left to guess why the action isn't allowed. I understand the convenience of adding ports to parts in the context of wiring stuff together in a capsule, but are the side-effects of this something that we really want?
This partly looks like a duplicate of Bug 486444, which (if I understand the scope correctly of that Bugzilla), should cover the drag-and-drop case, i.e. when you drag-and-drop the protocol onto the border of a capsule part. The case using the port creation tool on the palette in the capsule structure diagram, to create a port on the capsule part, and thus creating it on its typing capsule, might be something that we have not explicitly covered yet. Maybe this Bugzilla could be used to cover for both cases, and let this one be blocked by Bug 486444 for the protocol drag-and-drop case. Regarding the read-only scenario, I have a feeling that it should be a less common case. Especially this about deploying a library in a plugin (this is not something that I have ever seen the need for). Anyway, the case should probably be handled in some graceful way. But I don't feel that we need to put any effort in the aspect of making it more visible to the user that the capsule typing the capsule part is read-only. As you say, it is rather useful when working with a model, to be able to easily drag-and-drop a protocol directly onto the capsule part (and thus implicitly creating the port on the capsule), to quick and easy build up the model structure. So the "side-effect" I would say is exactly what you want. To always force the user to create the port in the context of the capsule, will just make certain editing scenarios a pain.
(In reply to Peter Cigehn from comment #1) > This partly looks like a duplicate of Bug 486444, which (if I understand the > scope correctly of that Bugzilla), should cover the drag-and-drop case, i.e. > when you drag-and-drop the protocol onto the border of a capsule part. Right you are. > As you say, it is rather useful when working with a model, to be able to > easily drag-and-drop a protocol directly onto the capsule part (and thus > implicitly creating the port on the capsule), to quick and easy build up the > model structure. So the "side-effect" I would say is exactly what you want. > To always force the user to create the port in the context of the capsule, > will just make certain editing scenarios a pain. Fair enough. I just wanted to make sure that we consider some of the marginal use cases.
We probably should consider Bug 490859 at the same time here, since the stop-sign (no-smoking cursor) appears also in the case when you want to create and internal behavior port using the port creation tool on the palette. Maybe they even are related and that Bug 490859 in fact also is blocking this one?
When important aspect to consider here, is the placement of the ports. Since we already have the functionality of placing the ports on the capsule part relative to the position of the port on the capsule, see Bug 482599, we have the need for the opposite here. Whenever you drop the port tool on the border of the capsule part to create a port on the corresponding capsule, the position of the port on the capsule should be relative to the position of where the port is placed on the capsule part. The same is of course applicable for the case of drag-and-drop of a protocol according to Bug 486444.
(In reply to Peter Cigehn from comment #4) > > Whenever you drop the port tool on the border of the capsule part to create > a port on the corresponding capsule, the position of the port on the capsule > should be relative to the position of where the port is placed on the > capsule part. I would expect any correct implementation of the port creation on the part to "just work" based on the current capsule-to-part synchronization. The part doesn't actually have a port; it has to be created on the part's capsule type in the first place. So what the tool should do is * register the location on the capsule-part's border where the user dropped the protocol or clicked the Port tool * translate that location to the border of the capsule on which the port must be created * create the port on that capsule * (then the mechanism currently in place automagically makes the port show up on the capsule-part in the expected place)
(In reply to Christian W. Damus from comment #5) > I would expect any correct implementation of the port creation on the part > to "just work" based on the current capsule-to-part synchronization. The > part doesn't actually have a port; it has to be created on the part's > capsule type in the first place. So what the tool should do is > > * register the location on the capsule-part's border where the user dropped > the protocol or clicked the Port tool > * translate that location to the border of the capsule on which the port > must be created > * create the port on that capsule > * (then the mechanism currently in place automagically makes the port show > up on the capsule-part in the expected place) Sounds good! I just wanted to make sure that the expected behavior was made clear.
(In reply to Peter Cigehn from comment #6) > > Sounds good! I just wanted to make sure that the expected behavior was made > clear. Yes, of course. And I just wanted to record a prescription for what I thought the solution would be, for posterity. I have no idea who may end up implementing this feature.
New Gerrit change created: https://git.eclipse.org/r/72219
Gerrit change https://git.eclipse.org/r/72219 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=643aeb5ab9160b97b1f6188d7fa8ff8fff6b28f4
(In reply to Eclipse Genie from comment #9) > Gerrit change https://git.eclipse.org/r/72219 was merged to [master].
New Gerrit change created: https://git.eclipse.org/r/72358
Gerrit change https://git.eclipse.org/r/72358 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=3004794398e2cd08280af2ce5dd3d894e7d5af7e
I've tested this in the latest Papyrus-RT build, and both the case with using the port creation tool from the palette, as well as the case when dragging-and-dropping a protocol, on to the border of a capsule part, now creates a port on the capsule in the same relative position that the port was placed on the capsule part. I do not have the access right to do so, but I suggest that we put this one into verified fixed. I assume that we at the same time should set Bug 486444 into resolved/verified fixed, since that one was supposed to cover the drag-and-drop case (which now also is resolved).
(In reply to Peter Cigehn from comment #13) Thanks, Peter!
I am satisfied with the verification.
