Community
Participate
Working Groups
When you toggle the kind of port from external behavior <-> SPP some graphical glitches and refresh issues can be seen depending on which border the port is placed on. This was originally discovered as part of Bug 476882 Comment 11. But to be able to close that Bugzilla this refresh issue is tracked by this separate Bugzilla. Detailed steps how to reproduce: 1) Create a new UML-RT model 2) Create a protocol 3) Create a capsule 4) Open the capsule structure diagram 5) Drag-and-drop the protocol onto the left border of the capsule to create an external behavior port. It is very important that it is placed on the left border of the capsule since the graphical glitch is mostly visible on the left border. 6) Select the created port in the model explorer (do not select the port in the capsule structure diagram) 7) In the properties view, select the "SPP" radio button 8) Observe how the notation for the port now has the square shape to the left and the circle shape to the right (making it look like an "External Behavior" and "SPP" at the same time) 9) Now click somewhere in the diagram 10) Now the notation is refreshed and the port is shown only as a circle (as expected for an SPP) 11) Select the port in the model explorer again (not in the diagram) 12) In the properties view, select the "External Behavior" radio button 13) Observer now the notation for the port now has the circle shape to the left and the square shape to the right (making it look like an "SPP" and "External Behavior" at the same time) 14) Now click somewhere in the diagram 15) Now the notation is refreshed and the port is shown only as a square (as expected for an External Behavior port) So there is definitively some refresh issue going on here causing the graphical glitch. Yes, the glitch goes away if you select something else at the step right after you switched between an external behavior port to an SPP, which then probably makes the complete refresh of the port. I get a feeling that only the inside of the capsule frame is refreshed, and the part of the port that is outside the frame is not refreshed, hence the reason why the right part of the port, i.e. the part of the port that is inside the frame, gets refreshed correctly, whereas the left part, i.e. the part of the port that is outside the frame, does not get refreshed. If you repeat the steps above and instead drop the protocol on the top border, then you will see that there will be slightly different graphical glitches, where smaller/bigger parts of the port is not refreshed correctly. So there is some issue with only refreshing the stuff that is inside some frame (not sure what boundaries that frame really is based on). If you place the port on the bottom or right border, then no graphical glitches can be seen, so then the complete port seem to be inside this "refresh frame".
Confirmed still an issue. Moving to New
I can now reproduce the error. I could not see it first, since the selection rectangle hides a part of the port shape - but it becomes evident at a higher zoom level.
(In reply to Ansgar Radermacher from comment #2) > I can now reproduce the error. I could not see it first, since the selection > rectangle hides a part of the port shape - but it becomes evident at a > higher zoom level. Yes, make the selection of the port in the model explorer, and not in the diagram. This ensures that you see the graphical glitch more clearly.
I had the "link with Editor" synchronisation active. In fact, it does not matter whether you select in diagram or model explorer, the behavior can just be seen better w/o the selection border. Btw the problem is also observable, if the port is on the top border, but to a smaller extend. A first analysis of the code shows that the problem is related to the clipping within the figure hierarchy. The class SelectableBorderedNodeFigure is a parent of the RTPortFigure. If called via the normal refresh, it has different clipping bounds compared to when the update is triggered via the port-type change: in case of the latter the clipping bounds correspond to a larger capsule (therefore no problem on the right and on the bottom). Yet the call stack seems to be identical. (In reply to Peter Cigehn from comment #3) > (In reply to Ansgar Radermacher from comment #2) > > Yes, make the selection of the port in the model explorer, and not in the > diagram. This ensures that you see the graphical glitch more clearly.
(In reply to Ansgar Radermacher from comment #4) > I had the "link with Editor" synchronisation active. In fact, it does not > matter whether you select in diagram or model explorer, the behavior can > just be seen better w/o the selection border. Sorry, that was what I (implicitly) meant with selecting in the model explorer, i.e. to avoid having the selection markers on the port. I did not consider the case with "link with editor", since I normally don't use that. > Btw the problem is also observable, if the port is on the top border, but to > a smaller extend. Yes, as I indicated in Comment 0, the graphical glitch can be seen when the port is placed on the left and the top borders. It is not visible when the port is placed on the right and bottom borders. The graphical glitch is slightly different between right and top borders, since the "refresh area" seem to "cut through" the port at different positions on the left vs. top borders.
New Gerrit change created: https://git.eclipse.org/r/82495
Gerrit change https://git.eclipse.org/r/82495 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=bd9a413b7282ae80168bdb5cdb35aba6119c8117
Fixed with gerrit merge. No need for additional handling of stacked ports, since they now fit into the normal port bounds (see fix for 500982).
Do you put this one into resolved fixed, or it is something remaining to be done? Not sure if there are some suitable unit tests that can be added to avoid regressions in this area.
I set to resolved (I think, it's very difficult to test whether the graphic corresponds to the expectation, but I've little experience with graphical tests).
Verified to be fixed in the latest Papyrus-RT build. It is now possible to toggle the port kind (including having the port replicated showing the stacking pattern), without graphical refresh issues on any of the borders (especially the left and top border which had it before). What can be noted though is that the behavior adornment does not re-orient when moving the port to another border. This is tracked by Bug 504059. Putting into verified fixed.
Closing as verified fixed.
