Bugzilla – Full Text Bug Listing
New Gerrit change created: https://git.eclipse.org/r/52616 Gerrit change https://git.eclipse.org/r/52616 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=f45cc3605cbec5d36874de77a47a6bcf5934ad73 WARNING: this patchset contains 1784 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire I am not sure if this has been implemented or not. I can see that a Gerrit patch has been merged to master, but the Bugzilla is still in status New. Also when testing this in the latest Papyrus-RT build, I do not get it to work. When I drop a protocol on the inside of the capsule in its structure diagram, then instead of a port being created, a collaboration use gets created. When trying to drop on the contour/border of the capsule you cannot drop at all (it is only possible to drop on the inside). Please clarify the actual status of this, and if it is even intended to work at this stage. Gerrit change https://git.eclipse.org/r/53485 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=c1ab9e2c3cc4a36e20c206705f3ef8962db2b813 (In reply to Eclipse Genie from comment #5) > Gerrit change https://git.eclipse.org/r/53485 was merged to [master]. > Commit: > http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/ > ?id=c1ab9e2c3cc4a36e20c206705f3ef8962db2b813 the gerrit patch containing feature has been accepted, but the code still needs some refactoring, so the bug won't be closed. I've tested the latest build where the first version of the patch had been pushed and found the same issue as when dropping a capsule to create a capsule part. When dropping the protocol you get up an additional dialog asking if you should create an external or internal behavior port (depending on where you drop, i.e. on the border or on the inside, which works fine) or only a "Drop". If you select the "Drop" option then a collaboration use gets created. In the same case as for drag-and-drop of a capsule to create a capsule part, this additional dialog should never be shown and the default of creating a port should already be selected. It does not make sense to ever create a collaboration use in a capsule composite structure diagram. One more thing that I can see, though it probably is not related to drag-and-drop as such, but there seem to be some issue with the selection and the properties view. When I have dropped the same protocol to create to different ports, the properties view becomes really confused and changing the properties of one port seem to change the properties of the other port as well. But not always, so it feels random. Maybe you can keep an eye on this as well. Probably it should go into its own Bugzilla but I just comment it here since I discovered after testing the drag-and-drop. Whe trying to drop at different locations, i.e. on the border or on the inside, it feels like the port gets create sligthly offset from where you actually dropped. When dropping on the inside, the port becomes placed slightly above and to the left of where you actually dropped. When dropping on the left/right border, the port gets created above where you drop. Dropping on the bottom/top border, the port gets created slightly to the left of where you dropped. It would be good if the port gets created with the position more centered to where you drop. New Gerrit change created: https://git.eclipse.org/r/54921 Gerrit change https://git.eclipse.org/r/54921 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=4f272b0bc82686c312ad1ba5e9abe6996e313790 I've tried this in the latest build again, and now the resulting position is more centered where you made the drop. At least when you drop inside creating an internal behavior port, and when you drop on the left/right border to create an external behavior port. But when you drop on the top/bottom, then it is still a bit misaligned. If you drop on the top/bottom border and to left then the resulting position is to the right of where you dropped. If you drop on the top/bottom border and to the right then the resulting position is to the left of where you dropped. If you drop on the middle on the top/bottom border, then you get the resulting port position where you dropped. Created attachment 256294 [details]
Screen shoot showing the circle in the upper left corner
Apart from that, there is now also a circle the pops up in the upper left corner when you create the first port. Additional ports seem to all add the same circle in the same position. The circle disappears when the last port of the capsule is being removed.
(In reply to Peter Cigéhn from comment #13) > Created attachment 256294 [details] > Screen shoot showing the circle in the upper left corner > > Apart from that, there is now also a circle the pops up in the upper left > corner when you create the first port. Additional ports seem to all add the > same circle in the same position. The circle disappears when the last port > of the capsule is being removed. For the circle, this was my bad. I pushed accidentally a prototype on Papyrus nightlies mars when pushing some other contribution. This should not be present if you update your papyrus installation. (In reply to Remi Schnekenburger from comment #14) > For the circle, this was my bad. I pushed accidentally a prototype on > Papyrus nightlies mars when pushing some other contribution. This should not > be present if you update your papyrus installation. I updated to the latest Mars build of Papyrus, and indeed the circle is gone. New Gerrit change created: https://git.eclipse.org/r/55573 The last update should fix NLS issue... Let me know if you still have the problem. For the multiplicity, a popup alert the user that the multiplicity is not the one expected. Best regards I see that this Bugzilla is put in resolved fixed, but from what I can see, the last Gerrit patch has not yet been merged to master (see Comment 16). I am not sure about the process being used, but it is a bit hard to verify the fix unless it actually has been included in the nightly build. It will be a bit hard to follow along when Bugzillas actually have been resolved and can be verified, if they are set to resolved to early. Any comments? Has it been put in resolved fixed to premature, or has it been missed to actually merge the Gerrit patch to main? Gerrit change https://git.eclipse.org/r/55573 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=91f7cc0bbabd03717282b65699730a68d6e6f62e (In reply to Eclipse Genie from comment #19) > Gerrit change https://git.eclipse.org/r/55573 was merged to [master]. > Commit: > http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/ > ?id=91f7cc0bbabd03717282b65699730a68d6e6f62e I am not sure what is going on here, when checking both this commit is not related to this Bugzillas but it is related to Bug 472884, which is still open (in assigned state). This Bugzilla has been put into resolved, but the merged commit was not related to it. Can someone please check which Bugzilla really is resolved so that I know what to test in the latest build. In fact, this Commit has been added here automatically, because the task Bug 472884 depends on this bug. In the field "Blocks" of this bug you can see the dependance to the other bugs Best regards (In reply to Celine Janssens from comment #21) > In fact, this Commit has been added here automatically, because the task Bug > 472884 depends on this bug. In the field "Blocks" of this bug you can see > the dependance to the other bugs > Best regards Okay, but if this bug is blocked by Bug 472884 (which is still open), how can this Bug be resolved? Still being confused about the state of this Bug. I tested this in the latest build, but the dialog as mentioned in Comment 7 still pops up. The slight misalignment when dropping on the top/bottom border is still there as mentioned in Comment 12 (actually this misalignment is actaully there as well for the left/right borders if you increase the size of the capsule border to be higher). There definitively also seem to be some severe refresh issues with the properties view after a port has been created with drag-and-drop. If you select the created port right after it has been created it shows the wrong properties. Steps to reproduce: 1) Create a new UML-RT model 2) Create a capsule 3) Create a protocol 4) Open the composite structure diagram of the capsule 5) First drag and drop the protocol onto the border of the capsule to create an external behavior port 6) Select the properties of the external behavior port 7) The properties view shows that is an external behavior port 8) Then drag and drop the same protocol on the inside of the capsule to create an internal behavior port 9) Now select the newly created internal behavior port 10) The properties indicates that the port is an external behavior port! 11) Select the capsule to get the properties view to show some other set of properties, and then select the internal behavior port again 12) Now the properties view shows that it is an internal behavior port So I would suggest that this Bugzilla is reopened again. Or is the idea to track the remaining issues in separate Bugzillas? (In reply to Peter Cigéhn from comment #23) > So I would suggest that this Bugzilla is reopened again. Or is the idea to > track the remaining issues in separate Bugzillas? I never got any response to this. I would prefer if this Bugzilla could be reopened so that we can track the remaining issues listed in Comment 23. Or do you prefer to have it tracked in separate Bugzillas? (In reply to Peter Cigéhn from comment #24) > I never got any response to this. I would prefer if this Bugzilla could be > reopened so that we can track the remaining issues listed in Comment 23. Or > do you prefer to have it tracked in separate Bugzillas? I wrote a separate Bugzilla for the refresh issue, see Bug 478553. (In reply to Peter Cigéhn from comment #23) > I tested this in the latest build, but the dialog as mentioned in Comment 7 > still pops up. The slight misalignment when dropping on the top/bottom > border is still there as mentioned in Comment 12 (actually this misalignment > is actaully there as well for the left/right borders if you increase the > size of the capsule border to be higher). Will this Bugzilla be reopened to handle these remaining issues? Or should I write new Bugzillas for those cases? It feels a bit too much administration to write Bugzillas for each individual issue related to new features like this. Or do you prefer that I write new Bugzillas for this kind of feedback? reopening to fix issues on comment 23 Hello Peter, here are the differents bug you mentionned and some details: 1) Misalignment of the Port when Drag and Drop: Probably due to Papyrus PortPositioinLocator - Maybe should be fixed into Papyrus instead of PapyrusRT ? As the issue is for the standard position of a Port. 2) PopUP for the wrong multiplicity If I understood well, you prefer do not have a warning pop up and make the system calculate the correct multiplicity ? What if the user enter 2..5? should it be 2 or 5 or 0..2 or 0..5? if the user enter a wrong one, maybe he would prefer to know that is a wrong one? 3) Refresh of the Property View. It is a known issue and is tracked into Bug 477033. I think this bug should not be part as this one. This is a Framework problem. Not only for the Kind property view. (In reply to Celine Janssens from comment #28) > Hello Peter, here are the differents bug you mentionned and some details: > > 1) Misalignment of the Port when Drag and Drop: > Probably due to Papyrus PortPositioinLocator - Maybe should be fixed into > Papyrus instead of PapyrusRT ? As the issue is for the standard position of > a Port. Can't really judge if it should be fixed in Papyrus or in Papyrus-RT. But if you say that it is a problem in base Papyrus then maybe it is better to fix it there. Since you know the details I suggest that you write the Bugzilla on Papyrus with the details that you know and make it block this Bugzilla. > > 2) PopUP for the wrong multiplicity > If I understood well, you prefer do not have a warning pop up and make the > system calculate the correct multiplicity ? What if the user enter 2..5? > should it be 2 or 5 or 0..2 or 0..5? if the user enter a wrong one, maybe he > would prefer to know that is a wrong one? After some off-line mail discussion, Bran will make updates to the UML-RT profile document and the UML-RT profile clarifying the rules for multiplicity. He will also add some constraints related to this to the UML-RT profile. I guess we could ensure that those constraints are being validated live, so there should not be any need to add specific code in the tooling to check this. If we make that a live-validation with error severity then the user will not even be able to change the model if an incorrect multiplicity is provided. As we have discussed before, it might be that the multiplicity (or actually maybe a better name will be 'replication') field in the Real Time tab should only manipulate upper bound. The lower bound shall only be changed by changing the kind of port, i.e. fixed, optional or plugin. So the only way that a user would be able to manipulate the lower bound would be if they used some of the detailed UML properties (which should be a rare case where the user will be "on his own"). And for that case I think that it should be sufficient with the constraint that is planned to be added to the UML-RT profile. We should really focus on that the user (in the normal case) cannot even enter an invalid multiplicity by ensuring the the 'replication' field only allows changing upper bound. > > 3) Refresh of the Property View. > It is a known issue and is tracked into Bug 477033. I think this bug should > not be part as this one. This is a Framework problem. Not only for the Kind > property view. I have already written a separate Bugzilla for that case, see Comment 25. So I agree it shall not be covered by this Bugzilla. But I really do not see that Bug 477033 has anything to do with Bug 478553. From my perspective they feel like two separate issues. The problem described in Bug 478553 feels like a general refresh issue, and does not seem related to the aspect the the different properties of the same port shall updated based on each other. The refresh issue in Bug 478533 is more that the properties of a previous port is shown when selecting a new one. But sure, I could be mistaken. Anyway, if they are related, then please make one of them depend on the other, depending on which one you feel is blocking the other. Just a reminder based on Comment 23 which references Comment 7 (since you did not mention it you previous comment with questions). The dialog asking how the drop shall be performed needs to have its default behavior set automatically (so you don't get it, even not the first time). As I said, it does not make sense to create a "collaboration use" in capsule structure diagram, so that popup should never be shown. (In reply to Peter Cigehn from comment #29) > > As we have discussed before, it might be that the multiplicity (or actually > maybe a better name will be 'replication') field in the Real Time tab should > only manipulate upper bound. The lower bound shall only be changed by > changing the kind of port, i.e. fixed, optional or plugin. So the only way > that a user would be able to manipulate the lower bound would be if they > used some of the detailed UML properties (which should be a rare case where > the user will be "on his own"). And for that case I think that it should be > sufficient with the constraint that is planned to be added to the UML-RT > profile. > > We should really focus on that the user (in the normal case) cannot even > enter an invalid multiplicity by ensuring the the 'replication' field only > allows changing upper bound. > Regarding the naming I checked the legacy tooling and in RoseRT it is called 'Cardinality' and even further back in ObjecTime and ROOM it was called 'Replication factor'. Maybe 'Cardinality' is a good name for the single field on the Real Time tab, which then maps to upper bound. See also this question on stack-overflow http://stackoverflow.com/questions/17877582/multiplicity-vs-cardinality I can ask around a bit and see what people's opinions are regarding this. This would then of course be a general naming, which also applies to the cardinality of capsule parts (and not only to the cardinality of ports). (In reply to Peter Cigehn from comment #31) > Regarding the naming I checked the legacy tooling and in RoseRT it is called > 'Cardinality' and even further back in ObjecTime and ROOM it was called > 'Replication factor'. > > Maybe 'Cardinality' is a good name for the single field on the Real Time > tab, which then maps to upper bound. > > See also this question on stack-overflow > http://stackoverflow.com/questions/17877582/multiplicity-vs-cardinality > > I can ask around a bit and see what people's opinions are regarding this. > This would then of course be a general naming, which also applies to the > cardinality of capsule parts (and not only to the cardinality of ports). Bran Selic pointed out that 'cardinality' has a very specific meaning in the UML spec, which is the current (dynamic) replication. The 'multiplicity' defines the static boundaries and constrains the 'cardinality'. If no one objects, I suggest then that we use the term 'replication', which has its origin in ObjecTime/ROOM. So we will have one field named 'Replication' on the Real Time tab. When changing the 'Replication' field it will only update the upper bound when the lower bound is zero and will update both lower bound and upper bound to the same value filled into the 'Replication' field for the case when lower bound is not zero. I realize that we have this discussion in the context of a Bugzilla dealing with ports, but this should also be applied for the 'replication' of a capsule part. Actually the case where lower bound is zero is only applicable for capsule parts, i.e. optional and plugin capsule parts. For ports the 'replication' field will always set lower and upper bound to the same value. (In reply to Peter Cigehn from comment #32) > (In reply to Peter Cigehn from comment #31) [...Snip...] > If no one objects, I suggest then that we use the term 'replication', which > has its origin in ObjecTime/ROOM. So we will have one field named > 'Replication' on the Real Time tab. When changing the 'Replication' field it > will only update the upper bound when the lower bound is zero and will > update both lower bound and upper bound to the same value filled into the > 'Replication' field for the case when lower bound is not zero. > > I realize that we have this discussion in the context of a Bugzilla dealing > with ports, but this should also be applied for the 'replication' of a > capsule part. Actually the case where lower bound is zero is only applicable > for capsule parts, i.e. optional and plugin capsule parts. For ports the > 'replication' field will always set lower and upper bound to the same value. +1 on using "Replication". I created two separate Bugzillas related to the 'replication' field. Please see Bug 479350 and Bug 479352. I am not sure if this is part of the scope of this Bugzilla, or if it should be a separate Bugzilla. But since there are work left with this Bugzilla I suggest to add this to the scope. We also need to support drag-and-drop of protocol where the drop target is a capsule part (or actually the contour/border of a capsule part). This should then create an external behavior port of the capsule used to type that capsule part. This is also related to the new child menu which allows you to right click on a capsule part in the model explorer, and then create a port. The same shall of course be possible to achieve using drag-and-drop. Currently in the latest Papyrus-RT build, only a stop-sign is shown when hovering and selecting a capsule part as a drop target. Hi Peter, In order to simplify the task traking, I suggest to close this bug, as the main feature has been done, and open a specific bugzilla for the Drag-and-Drop feature of a Port on a CapsulePart. The Multiplicity feature a Replication is treated in the Bug 479352. I Created a bug for the DnD of the protocol on the Capsule Part in the Bug 486444. Does it sound good to you ? Regards (In reply to Celine Janssens from comment #36) > In order to simplify the task traking, I suggest to close this bug, as the > main feature has been done, and open a specific bugzilla for the > Drag-and-Drop feature of a Port on a CapsulePart. > > The Multiplicity feature a Replication is treated in the Bug 479352. > > I Created a bug for the DnD of the protocol on the Capsule Part in the Bug > 486444. > > Does it sound good to you ? Before closing this Bugzilla, I really see that we need to fix the popup when drop according to Comment 7, where you need to select what to create. In the context of UML-RT and Papyrus-RT it does not make sense for the user to have to make this choice, you always create an external, or internal, behavior port (depending or where you drop) and the user should not have to be confronted with this popup menu. Sure the user can choose the default drop strategy, but that choice should have already been made for the user. Actually, if the user selects the choice "Drop", then a "CollaborationUser" is created in the model but it is not shown in the diagram. For the user this will be extremely confusing, so this choice should not even exist in the context of UML-RT and Papyrus-RT. If you want to close this Bugzilla then I suggest a separate Bugzilla for this aspect also is written, before closing this one. (In reply to Peter Cigehn from comment #37) > Before closing this Bugzilla, I really see that we need to fix the popup > when drop according to Comment 7, where you need to select what to create. > In the context of UML-RT and Papyrus-RT it does not make sense for the user > to have to make this choice, you always create an external, or internal, > behavior port (depending or where you drop) and the user should not have to > be confronted with this popup menu. > > Sure the user can choose the default drop strategy, but that choice should > have already been made for the user. Actually, if the user selects the > choice "Drop", then a "CollaborationUser" is created in the model but it is > not shown in the diagram. For the user this will be extremely confusing, so > this choice should not even exist in the context of UML-RT and Papyrus-RT. > > If you want to close this Bugzilla then I suggest a separate Bugzilla for > this aspect also is written, before closing this one. Just to be clear, this aspect of this popup dialog when you drop is also applicable for dropping a capsule to create a capsule part. Also in that case the user should not be confronted with this popup dialog, but the default of creating a capsule part is always applicable (it does not make sense to create an ordinary property typed by a capsule, which is also related to Bug 486367). Maybe am I wrong, but does the bug 472885 is enough for traking this ? (In reply to Celine Janssens from comment #39) > Maybe am I wrong, but does the bug 472885 is enough for traking this ? I have too limited insight to understand if Bug 472885 will also cover the case for dropping a protocol to create a port, since that Bugzilla only mentiones dropping a capsule to createa capsule part. And the referenced Bug 47556 only mention PropertyPart which I am not sure if that will cover also the aspect of creating ports. It feels better if we have Bugzilla for tracking the specific case of creating ports by drag-and-drop of a protocol. (In reply to Peter Cigehn from comment #40) > (In reply to Celine Janssens from comment #39) > > Maybe am I wrong, but does the bug 472885 is enough for traking this ? > > I have too limited insight to understand if Bug 472885 will also cover the > case for dropping a protocol to create a port, since that Bugzilla only > mentiones dropping a capsule to createa capsule part. And the referenced Bug > 47556 only mention PropertyPart which I am not sure if that will cover also > the aspect of creating ports. > > It feels better if we have Bugzilla for tracking the specific case of > creating ports by drag-and-drop of a protocol. Sorry, I should have written "...the referenced Bug 475569...". To my understanding the remaining issues to be resolved within the scope of this Bugzilla are: 1) The additional menu that pops up for selecting the drop action, i.e. to either create an external behavior port or an internal behavior port. The default action should be "pre-configured" and the user should never have to bother to make this selection. This is the same issue left for the related case of drag-and-drop of a capsule to create a capsule part in Bug 472885. 2) The position of the port still has an offset compared to the mouse pointer position. Instead of centering the port on the mouse pointer, the port ends so that mouse pointer is in: 1) the top left corner (for the internal behavior port case), 2) the top border (for the external behavior port case placed on the left or right border of the capsule), 3) the left border (for the external behavior port case placed on the top or bottom border of the capsule). Should we really continue keeping this Bugzilla open? Or write two new separate Bugzillas for the remaining two issues? Maybe even combine the aspect of removing the popup menu for selecting drop action for both the case of dropping a protocol and dropping a capsule. I assume it is the same kind of work that is needed for both cases. Are there any additional aspects left within the scope of this Bugzilla that I might have missed? The case for drag-and-drop of a protocol onto the border of a capsule part has already been moved to its own Bug 486444. Could Christian take a look at this one? Since Christian fixed the drag-and-drop case onto the border of a capsule part (without the additional popup appearing) in Bug 486444, maybe something similar could be made here? (In reply to Peter Cigehn from comment #43) > Could Christian take a look at this one? Since Christian fixed the > drag-and-drop case onto the border of a capsule part (without the additional > popup appearing) in Bug 486444, maybe something similar could be made here? I got lucky in bug 486444: Papyrus doesn't provide any drop strategies for collaborations on parts in the composite structure diagram, so now there is exactly one strategy and the system doesn't have to prompt the user. In this case, we do have competing strategies offered by Papyrus, so somehow those would have to be suppressed in the UML-RT context, which is new work (hopefully not requiring new API in Papyrus, otherwise we're probably looking at solving this in Oxygen). (In reply to Christian W. Damus from comment #44) > In this case, we do have competing strategies offered by Papyrus, so somehow > those would have to be suppressed in the UML-RT context, which is new work > (hopefully not requiring new API in Papyrus, otherwise we're probably > looking at solving this in Oxygen). I really think that this needs to be solved for 1.0 of Papyrus-RT. I find these additional popup to be very confusing a new user, and I personally find them extremely annoying all the time when using drag-and-drop (which should be the most efficient way of creating ports and capsule parts, but now just feels like a "pain" compared to what I am being used to). I am not sure that this is the "first impression last" that we want newcomers of Papyrus-RT 1.0 to experience. According to Remi's comment in Bug 472885 Comment 3, there seem to be a workaround for this. Not sure though if that is specific to the creation of capsule part case, or if it is applicable to ports as well. (In reply to Peter Cigehn from comment #45) > (In reply to Christian W. Damus from comment #44) > > In this case, we do have competing strategies offered by Papyrus, so somehow > > those would have to be suppressed in the UML-RT context, which is new work > > (hopefully not requiring new API in Papyrus, otherwise we're probably > > looking at solving this in Oxygen). > > I really think that this needs to be solved for 1.0 of Papyrus-RT. I find > these additional popup to be very confusing a new user, and I personally > find them extremely annoying all the time when using drag-and-drop (which > should be the most efficient way of creating ports and capsule parts, but > now just feels like a "pain" compared to what I am being used to). I am not > sure that this is the "first impression last" that we want newcomers of > Papyrus-RT 1.0 to experience. > > According to Remi's comment in Bug 472885 Comment 3, there seem to be a > workaround for this. Not sure though if that is specific to the creation of > capsule part case, or if it is applicable to ports as well. The workaround was unfortunately not working on Papyrus-RT. Some new policies and providers have been created together with Christian. Popup should not come anymore, and tests are being updated to ensure drop is working nice for the end users => the command to drop is taken directly from the edit part, not asked to the specific strategy. See https://git.eclipse.org/r/#/c/72512/ (In reply to Remi Schnekenburger from comment #46) > (In reply to Peter Cigehn from comment #45) > > (In reply to Christian W. Damus from comment #44) > > > In this case, we do have competing strategies offered by Papyrus, so somehow > > > those would have to be suppressed in the UML-RT context, which is new work > > > (hopefully not requiring new API in Papyrus, otherwise we're probably > > > looking at solving this in Oxygen). > > > > I really think that this needs to be solved for 1.0 of Papyrus-RT. I find > > these additional popup to be very confusing a new user, and I personally > > find them extremely annoying all the time when using drag-and-drop (which > > should be the most efficient way of creating ports and capsule parts, but > > now just feels like a "pain" compared to what I am being used to). I am not > > sure that this is the "first impression last" that we want newcomers of > > Papyrus-RT 1.0 to experience. > > > > According to Remi's comment in Bug 472885 Comment 3, there seem to be a > > workaround for this. Not sure though if that is specific to the creation of > > capsule part case, or if it is applicable to ports as well. > > The workaround was unfortunately not working on Papyrus-RT. Some new > policies and providers have been created together with Christian. Popup > should not come anymore, and tests are being updated to ensure drop is > working nice for the end users => the command to drop is taken directly from > the edit part, not asked to the specific strategy. > See https://git.eclipse.org/r/#/c/72512/ Gerrit change https://git.eclipse.org/r/72512 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=9c823e68677588fa4caa2bf58654d0db605ac402 I've tested this in the latest Papyrus-RT build. And yes, the additional popup do no longer appear, which is good. But another major issue now occurs instead. The drop position is ignored, and the created port/capsule part always gets created at the default position. Especially for ports this is rather confusing/annoying, since they are always positioned at the top right position and ends up on top of each other (as indicated in Bug 482920). I'm not sure what is worse, to have the additional popup, or not being able to position the port/capsule part already when selecting the drop position. If we are not able to respect the default position, then I really think I prefer to get the additional popup. The best is of course if we can solve this by both getting rid of the additional popup *and* respecting where the user chose to drop. (In reply to Peter Cigehn from comment #48) > I've tested this in the latest Papyrus-RT build. And yes, the additional > popup do no longer appear, which is good. > > But another major issue now occurs instead. The drop position is ignored, > and the created port/capsule part always gets created at the default > position. Especially for ports this is rather confusing/annoying, since they > are always positioned at the top right position and ends up on top of each > other (as indicated in Bug 482920). I fixed that problem in patch #3 on the gerrit change, yesterday (I was basing a bug fix of my own on the new edit-part provider in this patch). It looks like that fix was overridden by the next patch #4. I checked the Gerrit change, https://git.eclipse.org/r/#/c/72512/, and saw that Christian had made comment about this about the position, and also uploaded a patch set 3, that he claimed should have fixed the issue with keeping the drop position. What happened with the changes Christian proposed in patch set 3? (In reply to Peter Cigehn from comment #50) > I checked the Gerrit change, https://git.eclipse.org/r/#/c/72512/, and saw > that Christian had made comment about this about the position, and also > uploaded a patch set 3, that he claimed should have fixed the issue with > keeping the drop position. What happened with the changes Christian proposed > in patch set 3? Surprising, i thought patches>4 were fixing that issue, i will have a look this afternoon (In reply to Remi Schnekenburger from comment #51) > (In reply to Peter Cigehn from comment #50) > > I checked the Gerrit change, https://git.eclipse.org/r/#/c/72512/, and saw > > that Christian had made comment about this about the position, and also > > uploaded a patch set 3, that he claimed should have fixed the issue with > > keeping the drop position. What happened with the changes Christian proposed > > in patch set 3? > > Surprising, i thought patches>4 were fixing that issue, i will have a look > this afternoon Gerrit change https://git.eclipse.org/r/72915 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=afa5c9951797bb664c5e35da9a0c38dd4a02851e I've tested the latest Papyrus-RT build, and now the drag-and-drop of protocols works as expected, i.e. no additional popup appears, the port is positioned where you drop, and depending on where you drop either an external behavior port or an internal behavior port is created, i.e. dropping on the border of the capsule or inside. The slight offset as mentioned in Comment 42, bullet 2), is still there though. But since this offset is consistent with the offset when you drop the port tool on the palette and the offset is the same when creating ports also in base Papyrus, we leave that out of the scope of this Bugzilla. I suggest that we finally put this one into resolved/verified fixed. I myself do not have the access right to do so. Then I close the Bug |
One of the easiest way to create a new port is by drag-an-drop of a Protocol from the model explorer onto the composite structure diagram of a capsule. Two distinct drop targets can be identified: The contour of the capsule The inside of the capsule Depending on the drop target different types of ports is created, i.e. with different properties. When the drop target is the contour of the capsule then external behavior port, relay port or SPP can be created. When drop target is the inside of the capsuel then internal behavior port and SAP can be created. Initially it is enough with the default of always creating an external behavior port when dropping on the contour and always creating an internal behavior port when dropping on the inside is enough. Changing to another type of port can initially be made as a second step by directly changing the port properties.