Community
Participate
Working Groups
Since Papyrus Neon, Ports can be resized, which should not be possible in Papyrus-RT. The css rule to manage port resize should be set to false.
New Gerrit change created: https://git.eclipse.org/r/73912
*** Bug 492636 has been marked as a duplicate of this bug. ***
Gerrit change https://git.eclipse.org/r/73912 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=dbd7e2279aded0f17d629ddf16a9bac9db8cfe7b
Contribution merged. It indeed fixes also the duplicate bug 492636.
(In reply to Remi Schnekenburger from comment #4) > Contribution merged. > > It indeed fixes also the duplicate bug 492636. But it's odd that the resizing feed-back is shown, indicating the space that will be occupied by the resized port, but the cursor changes to the no-smoking sign. On releasing the mouse, the feedback just evaporates and the port remains unchanged. I would prefer that the resize handles not be shown on ports at all.
(In reply to Christian W. Damus from comment #5) > (In reply to Remi Schnekenburger from comment #4) > > Contribution merged. > > > > It indeed fixes also the duplicate bug 492636. > > But it's odd that the resizing feed-back is shown, indicating the space that > will be occupied by the resized port, but the cursor changes to the > no-smoking sign. On releasing the mouse, the feedback just evaporates and > the port remains unchanged. I would prefer that the resize handles not be > shown on ports at all. I completely agree. When the ports were able to be resize, I have numerous times resized them by mistaken, when I intended to move them. And if the resize handles still are there, but the only difference is that they "jump back" to its original size, then users will continue to do the same mistake, i.e. they plan on moving the port, but instead grap one of the resize handles. This will be an extremely annoying user experience after a while. If the ports have been marked as not being resizable, then they should not have any resize handles. I am not sure how to proceed here. Since I assume that we need a Bugzilla on Papyrus to solve this, should we then keep this Bugzilla open, i.e. reopen it, and let it be blocked by the new Papyrus Bugzilla. Or should we say that the intention of this Bugzilla has been fixed, and then write two new Bugzillas (one on Papyrus-RT and one on Papyrus) for tracking that the resize handles shall be removed? But knowing from experience how easy it is for reopened Bugzillas to just get "forgotten", I suggest that put this one into verified, and write new ones. I can write the one on Papyrus-RT, but I suggest that someone with bigger insight into CSS and how the Papyrus Bugzilla needs to be formulated writes that one.
Closing as verified fixed.
