Community
Participate
Working Groups
Created attachment 256440 [details] Screen shot from UML-RT profile document regarding port notation As can be seen from the screen shot from the UML-RT profile document, the notation for an RTPort should be according to the following principles: 1) Conjugated ports should have a white fill ("non-filled"), whereas un-conjugated ports should be filled (with the same color as the border of the port). This to ensure that conjugated vs. un-conjugated ports are clearly diffentiated (without having to show the type label for a port which included the tilde ~ character for comjugated ports). 2) Unwired ports should be black circle, whereas wired ports should be a square. This to ensure that it is easy to distinguish ports that actually should have a connector, from those that never will be connected using a connector. Both these principles shall be applied for ports of a capsule, as well as port on the border of a capsule part. This is related to Bug 474382 which is about the notation for behavior ports.
*** Bug 482654 has been marked as a duplicate of this bug. ***
Created attachment 258363 [details] Screen shot showing port notation in latest build of Papyrus-RT I checked the port notation in the latest build of Papyrus-RT. I am not sure what to think about the slightly "bluish" color, which also has some gradient fill (and not a solid fill). According to the proposal in the UML-RT profile document the fills should be completely black (no gradient) with the same color as the current line color, in the same way as the behavior adornment have a solid black filling. Bran, do you have any opinion about the current coloring? Is to "solid black" enough, or is it fine with the "bluish" gradient fill? Personally I think that if we shall have this fill color for unconjugated ports, then it should be a solid black fill color to really make them stand out compared to the conjugated ports.
See Bug 477033 Comment 25 regarding some graphical glitches when switching between different kinds of ports. Maybe that issue should be handled within the scope of this Bugzilla.
Comment on attachment 258363 [details] Screen shot showing port notation in latest build of Papyrus-RT It is so much simpler and easier to spot and identify the conjugation value of ports if the simple rule outlined in the RT profile document is supported: simple black fill (no gradient) and simple white fill (for conjugated ports). I would advise against using the "bluish" gradient variant.
Created attachment 258390 [details] Screen shot showing difference of ports on capsule vs. capsule part in legacy tooling Currently the ports on a capsule part is the same size as ports on the capsule itself. In legacy tooling, all the way back to ObjecTime and RoseRT, the ports on the the capsule parts have been smaller than the ports on the capsule. Since the capsule parts normally are much smaller than its corresponding capsule, you need to be able to fit in all the service ports on the border of the capsule to also fit on the corresponding capsule part. See for example Bug 482599 regarding the relative positioning of ports on capsule part. I sugges that it is considered to reduce the size of the ports on a capsule part to something like 2/3 of the size of the normal port (which seem to be comparable to relative sizes seen in the screen shot from the legacy tooling).
Created attachment 258393 [details] Screen shots showing three different kinds of glitches As identified Bug 477033 Comment 25 there are some graphical "glitches" when toggling back and forth between SPP and external behavior port (and further to relay port), i.e. when changing the notation from a square to a circle and vice versa. It seem to work when switching back and forth between SAP and internal behavior port, as it only happens for ports on the border of the capsule. This is best seen if you select the port in the model explorer and observe the changes in the diagram (do not select the port in the diagram since the selection markers on the port partly hides what is going on). The transitions that causes problems are: 1) External behavior port -> SPP 2) SPP -> External behavior port 3) SPP -> External behavior port -> Relay
Gerrit change https://git.eclipse.org/r/61747 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=396e20b272eadb63b0537a42fbd65dccd793e51b
Ok for the filling, I set it to Black and White without gradient , as in your attatchment. Is it that what you want ? About the glitches, I cannot reproduce it. Could you check if without the gradient, they are still present? Thanks
Created attachment 258427 [details] Screen shot showing all kinds of ports conjugated and un-conjugated (In reply to Celine Janssens from comment #9) > Ok for the filling, I set it to Black and White without gradient , as in > your attatchment. > > Is it that what you want ? Yes, now it looks exactly as Bran specified in the UML-RT profile document. The conjugated port is clearly distinguishable from the un-conjugated port. So this look like as expected. I have made a screen-shot so that Bran can see how it looks like after the update.
(In reply to Celine Janssens from comment #9) > About the glitches, I cannot reproduce it. > Could you check if without the gradient, they are still present? The graphical glitches are still there in the latest Papyrus-RT build (0.7.1.201512022319). 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 or the bottom, 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 bundaries that frame really is based on). If you place the port on the right border, then no graphical glitches can be seen, so then the complete port seem to be inside this "refresh frame".
Thanks Peter and Celine. It looks good to me. Regarding the refresh problem, I've run into similar problems in a number of diagrams, so I suspect that it is a more general issue than just for ports. Of course, I could be wrong. I have documented and raised the issues with the CEA List team, but have not raised bugzilla items.
Bran, did you see my Comment 5 regarding the size of the ports visualized on the capsule part? Any opinion regarding this?
Yes, I did see your comment, and I agree with it. However, for me it is a question of esthetics and I did not want to create a major work item for someone (if that is what it means) at a time when I suspect there are bigger issues to deal with. That said, I repeat, I agree that there should be a difference in size. We should fix it now, if it is a small development item, otherwise, we can fix it later.
There has been no activity on this bug since last December (almost 9 months), except for a "see also" link added in March and since fixed. Also, the notation seems correct in Papyrus-RT version 0.7.2.201608261452. I also could not see any of the glitches illustrated in the attachment. Can this bug be closed?
(In reply to Charles Rivet from comment #15) > There has been no activity on this bug since last December (almost 9 > months), except for a "see also" link added in March and since fixed. This is yet one more of those Bugzillas that simply have gotten "stuck". Most of it is indeed done, but there are still some remaining issues. I have been planning on writing new, more detailed Bugzillas, for the remaining issues to avoid getting "stuck" like this. > > Also, the notation seems correct in Papyrus-RT version 0.7.2.201608261452. > > I also could not see any of the glitches illustrated in the attachment. The graphical issues still occurs when switching between external behavior ports to SPP for ports located on the left and top border. When placed on the bottom and right border, the refresh seem to be okay. There have also been graphical refresh issues for replicated ports (with the stacking pattern), but that I have not seen in a while. > > Can this bug be closed? My plan was to write new Bugzillas, e.g. regarding the refresh issue. We already have Bug 497825 for the stacking pattern on ports, which now works at least partly. It works for ports on capsules, but we still have issues with ports on capsule parts, where the stacking pattern does not work. I will update Bug 497825 with this information.
(In reply to Peter Cigehn from comment #16) [...snip...] > > Can this bug be closed? > > My plan was to write new Bugzillas, e.g. regarding the refresh issue. We > already have Bug 497825 for the stacking pattern on ports, which now works > at least partly. It works for ports on capsules, but we still have issues > with ports on capsule parts, where the stacking pattern does not work. I > will update Bug 497825 with this information. +1 on the plan. Let's get this closed for 0.8.
I wrote Bug 500751 to track the remaining graphical refresh issue. Putting this one into resolved fixed. The notation for ports are now aligned with the UML-RT profile document. Conjugation is shown as black or white fill, and wired/unwired ports is shown as squares/circles. The size of the ports on capsules respectively on capsule parts are aligned with legacy tooling. The aspect of the stacking pattern for replicated ports on capsule parts is still an issue, but that is already tracked in Bug 497825. Putting this one into resolved fixed.
Verified that the port notation is aligned with the UML-RT profile document.
Closing as verified fixed.
