Community
Participate
Working Groups
Created attachment 265652 [details] Example model that showcases the issue with inconsistent port positions When importing a legacy model with capsule structure diagrams where the layout of ports uses a mix of manually placed ports and ports which are positioned automatically by the legacy tooling, the resulting model can get a rather inconsistent position of ports. It seems that some of the ports that have an automatic position in the legacy model, do get the same (or at lest corresponding) position by the automatic layout in Papyrus-RT, whereas other ports gets "stuck" in the top left corner. When importing the attached model into Papyrus-RT a few things can be noted: 1) The port p2Short, which has an automatic position in the source model, gets "stuck" in the top left corner 2) The port p4Longest, which also has an automatic position in the source model, do get an automatic position in Papyrus-RT. I can be noted that when opening the diagram the first time in a newly opened model editor, that the port "jumps" from the top left corner, down to the middle of the left frame (as expected). 3) Port label positions (which all have their default automatic position in the source model) have slightly different position in Papyrus-RT, especially the p4Longest which I assume both have the port and label position automatically adjusted in Papyrus-RT. The other labels have a different position vertically compared to the source (looks like it is left aligned with the left border of the port shape, whereas the label in the legacy tooling seem to be center aligend with left border of the port shape). All in all, this causes the layout of ports to be rather inconsistent in user models which have a mix of automatic position of ports (and labels) vs. manually positioned ports (and labels). Not sure either if this is an issue only with the automatic layout in Papyrus-RT, that needs to handle both the case with port p2Short and p4Longest, and not only p4Longest.It can of course be questioned if the automatic layout really shall move the port label to the left of the port as it is done now, or respect the position it had in the source model. There is of course a possibility that something needs to be done in the actual import. But I guess we first need to check the automatic layout in the tooling to see if if can handle this imported model in a better way.
Created attachment 265653 [details] Screen shot both showing the legacy model and imported result In this screen shot you can see both the source legacy model and the position of the ports and the result after importing to Papyrus-RT. To be noted is that the p2Short and p4Longest both have an automatic position in the source model, whereas p1 and p3Longer have both been manually positioned in the source model.
To clarify: This example model only have one port that gets stuck in the upper left corner. In other, actual models, there are cases where multiple ports (which have an automatic position in the source model) all get stuck, overlapping each other, in the top left corner, which makes the resulting diagram really hard to read.
Created attachment 265654 [details] Screen shot showing Diagram Assistant error dialog One more thing to be noted: When the imported diagram is open, there is an error dialog related to the Diagram Assistant that pops up from time to time, indicating a null pointer exception. No further information is provided in the error log, only the fact that a null pointer exception have occurred. So apart from the layout issues, there seem to something with the imported diagram that causes the Diagram Assistant to get a null pointer exception.
(In reply to Peter Cigehn from comment #3) > Created attachment 265654 [details] > Screen shot showing Diagram Assistant error dialog > > One more thing to be noted: When the imported diagram is open, there is an > error dialog related to the Diagram Assistant that pops up from time to > time, indicating a null pointer exception. No further information is > provided in the error log, only the fact that a null pointer exception have > occurred. So apart from the layout issues, there seem to something with the > imported diagram that causes the Diagram Assistant to get a null pointer > exception. For this last issue: is the error log a bit more explicit?
(In reply to Remi Schnekenburger from comment #4) > (In reply to Peter Cigehn from comment #3) > > Created attachment 265654 [details] > > Screen shot showing Diagram Assistant error dialog > > > > One more thing to be noted: When the imported diagram is open, there is an > > error dialog related to the Diagram Assistant that pops up from time to > > time, indicating a null pointer exception. No further information is > > provided in the error log, only the fact that a null pointer exception have > > occurred. So apart from the layout issues, there seem to something with the > > imported diagram that causes the Diagram Assistant to get a null pointer > > exception. > > For this last issue: is the error log a bit more explicit? When I saw this the first time, as I wrote above, I thought that I could not see any additional information in the error log. When I tried to repeat it again, I realized that this probably is issue with our custom tooling on top of Papyrus-RT (some custom matcher on top of the element type framework crashes with a null pointer). I was unable to repeat in a base Papyrus-RT installation. So I suggest that we disregard from the issue in Comment 3, at least for now.
I analyzed the attached model (RSA model) and found that for the port that has wrong position (gets stuck in the upper left corner) which is p2Short, there is a eAnnotation and a specific layout for the port shape with no specific bounds, that means that this is not an automatic position created by RSA. because there is a specific eannotation (PortShape with layout constraint) Papyrus RT model import create a specific Port_Shape with the specific layout , and then, because x=y=0 the port will be on the top left of the capsule. For p4Longest, there is no Port Shape in the *.emx it is really a port created with the automatic layout.
(In reply to smaoui asma from comment #6) > I analyzed the attached model (RSA model) and found that for the port that > has wrong position (gets stuck in the upper left corner) which is p2Short, > there is a eAnnotation and a specific layout for the port shape with no > specific bounds, that means that this is not an automatic position created > by RSA. because there is a specific eannotation (PortShape with layout > constraint) Papyrus RT model import create a specific Port_Shape with the > specific layout , and then, because x=y=0 the port will be on the top left > of the capsule. > > For p4Longest, there is no Port Shape in the *.emx it is really a port > created with the automatic layout. Yes, I have made the same analysis myself (it took some tries to reproduce a notation model that looked like this, since I cannot attach the actual production model to the bug where there are lots of these cases) and made the same kind of conclusion. Maybe I misunderstand what you mean, but I would not say though, that the port that has not specific bounds does not have automatic position in the legacy tooling. That is exactly what is the case: Both the port which does not have any shape at all defined in the notation model, as well as the port which have a shape (partly) defined but without bounds, both get automatically positioned by the legacy tooling (as can be seen from the screen shot from the legacy tooling). So these are just two different cases of automatic layout in the legacy tooling, which I assume both needs to handled by the import tool (or by the automatic layout in Papyrus-RT). I am not sure if this is your final analysis (I cannot really conclude what is the proposed solution) or not, and I cannot really say how it shall be solved. But to me it feels like if a port shape don't have an explicit bound specified in the notation model, then it cannot be assumed that it shall be positioned at x=y=0, but it needs to have the same kind of auto-layout as ports with no shape at all.
> I am not sure if this is your final analysis (I cannot really conclude what > is the proposed solution) or not, and I cannot really say how it shall be > solved. But to me it feels like if a port shape don't have an explicit bound > specified in the notation model, then it cannot be assumed that it shall be > positioned at x=y=0, but it needs to have the same kind of auto-layout as > ports with no shape at all. Yes this is what I want to propose, but I am still not sure that the layout out with specific bounds x=y=0 correspond to an automatic port shape position. when I create a port from the model explorer view, RSA did not create a shape for the port. I should be able to reproduce the second case where an automatic port layout correspond to a specific Shape with defined layout bounds x=y=0. do you remember how to reporduce this specific type of automatic layout ?
OK, I succed in reproducing the 2 cases : - first case of port with automatic layout : if we create a port (from the palette or from the model explorer), RSA create a port with an automatic layout (no shape created in the notation) - second case: if we create another port with automatic layout (no shape in the notation) and move it to a specific point --> result RSA create a shape for each port (a shape with a specific layout : bounds = bounds specified by the use) and a shape for the already created automatic port layout, that we did not move , but RSA add a shape for it in the notation with a specific layout x=y=0. I will propose the fix that you already proposed Peter. if the bounds = (0,0) set the port layout to the automatic Papyrus RT layout
(In reply to smaoui asma from comment #8) > Yes this is what I want to propose, but I am still not sure that the layout > out with specific bounds x=y=0 correspond to an automatic port shape > position. when I create a port from the model explorer view, RSA did not > create a shape for the port. I should be able to reproduce the second case > where an automatic port layout correspond to a specific Shape with defined > layout bounds x=y=0. > > do you remember how to reporduce this specific type of automatic layout ? (In reply to smaoui asma from comment #9) > OK, I succed in reproducing the 2 cases : > - first case of port with automatic layout : if we create a port (from the > palette or from the model explorer), RSA create a port with an automatic > layout (no shape created in the notation) > > - second case: if we create another port with automatic layout (no shape in > the notation) and move it to a specific point --> result RSA create a shape > for each port (a shape with a specific layout : bounds = bounds specified by > the use) and a shape for the already created automatic port layout, that we > did not move , but RSA add a shape for it in the notation with a specific > layout x=y=0. Yes, as I said, it was not obvious to reproduce this, but if I remember correctly I did about the same steps as you describe above. I and Christian had some discussion about how the notation model "virally" is persisted, see 467545 Comment 8 and some following comments. So as soon as you start moving around something that has auto-layout/position, other shapes with also have auto-layout/position also gets (partly) persisted (even though that it should not really be needed). See Christian's explanations about GMF runtime.
I proposed a fix for Bug 509338 fixing the semi automatic port layout
already fixed in Papyrus model importer : see Bug 509338
Verified to be fixed in the latest Papyrus-RT build, based on the latest Papyrus build. The ports with auto-layout position in the legacy model, now all get an auto-layout position after import as well. The port label position though is slightly different (positioned to the right of the port after import vs. centered above the port in the legacy model), but that is another issue not tracked by this bug. Putting into verified fixed.
Closing as verified fixed.
Updating target milestone to 0.9.0 to indicate that this one has already been fixed and will be included in 0.9.0 release.
