Bugzilla – Full Text Bug Listing
| Summary: | [Tooling] Service ports are no longer shown on the border of the capsule in Neon | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Papyrus-rt | Reporter: | Peter Cigehn <peter.cigehn> | ||||
| Component: | tool | Assignee: | Remi Schnekenburger <rschnekenburger> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | charles, papyrus-bugs, rschnekenburger | ||||
| Version: | 0.7.2 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 491156 | ||||||
| Attachments: |
|
||||||
Could this be related to the regression introduced by Bug 473722? Regression introduced on Bug 473722 has been fixed. I am now waiting for a nightly build of Papyrus to be issued to test that regression. I've tested this with the latest Papyrus-RT build, including the latest Papyrus build. And indeed the positioning of service ports are now on top of the border of the capsule as expected. There still seem to be an issue with the toggling case though. Changing a service port, to a non-service port never moves the port to the inside of the capsule. The port is "stuck" on top of the border of the capsule. Steps to reproduce: 1) Drag-and-drop a protocol onto the border of capsule to create an external behavior port 2) Change it to an internal behavior port using the radio button 3) See how the port is still "stuck" on top of the border of the capsule If you start with making the port a internal behavior port, and the toggle it to be an external, and then toggle it back to internal again, then the port is moved back and forth between the inside and the border. It only seem to be when the port originally was created on top of the border that causes it to be stuck there. I also tested this about resizing the port, and I am not sure what to think about that. Sure, in some cases it could be useful for wired ports, but I never expect it to be of any use for unwired ports (which have the circle shape). Also the fact that you can change the size in both directions, which can cause the ports to not look like ports at all. It could make sense to be able to resize the port only in the direction of the border, i.e. ports positioned to the left/right border can be resized up/down, and ports positioned on the top/bottom border can be resized to the left/right, ensuring that we always have the port fixed size in one direction. Also this about resizing them can cause even further confusion regarding the port on the "inside" of the capsule vs. on the "outside" of the capsule, i.e. the ports on capsule parts typed by the capsule. Apart from keeping the position, we then also need to consider also keeping the relative size. Since we in legacy tooling for UML-RT never ever have had the possibility of resizing the port (they have always been square and fixed sized), I am not sure what the best thing to do is, since we don't have any "best practice" or experience to rely on. I was indeed wondering at which extent it would be preferable in Papyrus-RT to remove this resize capability of the ports. What do you think? Should we go for non-resizable ports? It is probably best to remove the possibility of resizing them. Sure if a strong need arises, then we can consider enabling it later (probably with some limitations as I made in Comment 4). But for now I think it is best to align with legacy (and also how they are described to look like in the UML-RT profile document), and remove the possibility to resize them (as I understood it, this was a easily done using a CSS rule). (In reply to Peter Cigehn from comment #6) > It is probably best to remove the possibility of resizing them. Sure if a > strong need arises, then we can consider enabling it later (probably with > some limitations as I made in Comment 4). But for now I think it is best to > align with legacy (and also how they are described to look like in the > UML-RT profile document), and remove the possibility to resize them (as I > understood it, this was a easily done using a CSS rule). I completely agree with Peter stance on this. Although not relevant for 1.0 but interesting from an architectural point of view, a common desirable feature often expressed by RoseRT/RSARTE users, and therefore of interest for Papyrus-RT, is to be able to create "buses" (sets of ports and connectors between two capsule parts). Such a bus would then need both collapsed expended representations. This will likely require separate UI elements to represent the bus, but I would be worried about the potential complexity of the expansion mechanism if we can also change the size of the ports. Until we have a better idea of the solution for this upcoming requirement, I believe we should be conservative on our approach for the graphical representation of ports. Yes, the needs regarding "buses" and "cables" has been lacking for very long time (I actually raised the need for this already when I met Bran in person for the first time back in 2001 or something like that). I think that the paper that Seb sent out after our kick-off workshop in Paris 1.5 year ago, was really interesting. Take a look at https://www.researchgate.net/publication/221223478_Designing_Heterogeneous_Component_Based_Systems_Evaluation_of_MARTE_Standard_and_Enhancement_Proposal It has some ideas of how complex ports and connectors can be handled. Probably useful as input to any discussions in this area. (In reply to Peter Cigehn from comment #3) > There still seem to be an issue with the toggling case though. Changing a > service port, to a non-service port never moves the port to the inside of > the capsule. The port is "stuck" on top of the border of the capsule. > > Steps to reproduce: > > 1) Drag-and-drop a protocol onto the border of capsule to create an external > behavior port > 2) Change it to an internal behavior port using the radio button > 3) See how the port is still "stuck" on top of the border of the capsule > > If you start with making the port a internal behavior port, and the toggle > it to be an external, and then toggle it back to internal again, then the > port is moved back and forth between the inside and the border. It only seem > to be when the port originally was created on top of the border that causes > it to be stuck there. I've tested this in the latest Papyrus-RT build (with the latest Papyrus build), and this issue about the port being "stuck" when toggling the kind of port seem to have been fixed. It now works to toggle a port being a service/non-service port, and the port moves as expected from the border to the inside. This seem to work both using the radio buttons as well as isService check box. The original issue with ports not being displayed on the border still seem be fixed, apart from the four courner cases reports in Bug 492458 and tracked by Bug 492512 on the Papyrus-RT side. I suggest that we close this one, since the original issue seem to be fixed. The aspect of resizing the ports I think we should have a separate Bugzilla for. I have now bumped in several occasions when moving a port, instead ended up in resizing the port by mistake instead. So I really think that we shall make them fixed in size for now as stated in Comment 6 and Comment 7. Verified in the latest Papyrus-RT (with the latest Papyrus) build. The service ports are now placed on the border as expected. The four corner cases does not work, but are tracked by Bug 492512, and the resize case is tracked by Bug 49263. (In reply to Peter Cigehn from comment #10) > Verified in the latest Papyrus-RT (with the latest Papyrus) build. The > service ports are now placed on the border as expected. The four corner > cases does not work, but are tracked by Bug 492512, and the resize case is > tracked by Bug 49263. That should be Bug 492636 for the resize case. Mass closing already verified fixed/worksforme/wontfix bugs. |
Created attachment 260842 [details] Screen shot showing service port not on top of border When testing the latest Papyrus-RT build based on Neon, service ports (external behavior, relay and SPP) are no longer shown on the actual border of the capsule. Instead they are placed next to the border, but on the "inside". Steps to reproduce: 1) Create a new UML-RT model 2) Create a capsule and protocol in the model 3) Drag-and-drop the protocol onto the border of the capsule in the capsule's structure diagram 4) Note how the create port is placed next to the border, put on the inside, and not on top of the border (as it was in Mars). 5) Try to toggle the kind of port either using the radio buttons or the isService check-box to switch between service and non-service ports. 6) See how service ports never are placed on top of the border.