Community
Participate
Working Groups
Created attachment 267079 [details] Legacy example model with a state-machine with different sized states The size of states in Papyrus-RT is currently very narrow. There is for example no margin at all between the name label and the border of the state frame, making it hard to read. This should preferably be aligned with the legacy tooling, to also ensure that the layout of the imported state-machine diagrams can be kept as similar as possible. We have already done similar alignments regarding the size of capsule parts to keep the layout as similar as possible, see Bug 497841 for example. To avoid similar issues when we want to import state-machine diagrams, we need to make similar adjustments. Two major differences can be seen: 1) The use of an element icon in the legacy tooling. This actually seem to be a general bug, since even if Papyrus do support the use of element icons, it does not seem to work. Even if the "Element icon" check-box on the Appearance tab in Papyrus-RT is checked, indicating that an element icon should be used, it does not seem to have any effect. 2) The margins between the state shape frame and the name label seem to be very small (if any margin at all), causing automatically sized states (which adjust automatically based on the length of the state name label) to be much smaller compared to the legacy tooling. If the element icon is introduced according to 1, then the decorator for indicating a redefined state should preferably also be aligned with legacy tooling and be located on the element icon (instead of in the top right corner of the shape itself).
Created attachment 267080 [details] Screen shot showing the layout of the legacy model This screen shot shows the state-machine diagram from the model attached to Comment 0. Note how the transitions have no bend points, since the position of the states are aligned according to their size making the transitions to be without bend-points.
Created attachment 267081 [details] Screen shot showing the imported result This screen shot shows how the imported result looks like. As can be seen, the transitions now have additional bend-points, and the entry/exit points have in several cases been placed on the right border, instead of the bottom border, due to the smaller size of the state.
When looking at the screen shots, it looks the margin between the name label/element icon to the state shape frame, it looks like around 12 pixels. When comparing with the current margins in Papyrus-RT it looks like a margin of 0-1 pixel. When checking the default size of a state, i.e. if the state have a very short name, then size looks to be 80 x 50 pixels. I suggest to align with this default size in Papyrus-RT as well.
Is this only a problem for models imported from RSA-RTE? IF it is, then let's move to future.
(In reply to Simon Redding from comment #4) > Is this only a problem for models imported from RSA-RTE? IF it is, then > let's move to future. No, I would say that this is not only a problem with imported models. This I would say is general improvement, even if we disregard from the import aspect. Aligning the margins with legacy models improves the look-and-feel of the state machine diagrams in general in Papyrus-RT. And the aspect with the element icon I would claim is a bug (in base Papyrus though I guess, so when some investigations have been made on the Papyrus-RT side a separate bug might be needed for base Payrus). So for now I would like to keep this one for 1.0, even if we disregard from the import aspect.
Peter: Could we split this bug in two? One to deal with the Papyrus-RT "native" look and feel and a second one to deal with the importer?
(In reply to Charles Rivet from comment #6) > Peter: Could we split this bug in two? One to deal with the Papyrus-RT > "native" look and feel and a second one to deal with the importer? Can't we simply just let this bug focus on the look and feel (by aligning with legacy) but disregard from the actual import aspect. I have never expected this bug to actually have an impact on the import tool itself. So from my point of view we could keep this bug as-is. If we would split it in two I really don't see that the bug related to the import tool would have any impact at all. So it feels kind of meaningless to make such a split.
(In reply to Peter Cigehn from comment #7) > (In reply to Charles Rivet from comment #6) > > Peter: Could we split this bug in two? One to deal with the Papyrus-RT > > "native" look and feel and a second one to deal with the importer? > > Can't we simply just let this bug focus on the look and feel (by aligning > with legacy) but disregard from the actual import aspect. I have never > expected this bug to actually have an impact on the import tool itself. So > from my point of view we could keep this bug as-is. If we would split it in > two I really don't see that the bug related to the import tool would have > any impact at all. So it feels kind of meaningless to make such a split. Fine by me.
Adding back the depends_on_papyrus tag since this bug probably will need fixing in Papyrus to be able to show the element icon (which looks like an issue already in base Papyrus). Keep the tag until it a more detailed analysis have concluded that a work around can be made locally in Papyrus-RT.
(In reply to Peter Cigehn from comment #9) > Adding back the depends_on_papyrus tag since this bug probably will need > fixing in Papyrus to be able to show the element icon (which looks like an > issue already in base Papyrus). Keep the tag until it a more detailed > analysis have concluded that a work around can be made locally in Papyrus-RT. This seems to be the wrong way about. How can we depend on a Papyrus fix when we don't even know yet that we will need a Papyrus fix? This is more confusing than it should be. Also, if we disregard the import aspect, this appears to be a (simple?) sizing/spacing problem on creation. Again, if we disregard the import aspect, the the "See also" to bug 497841 would also be irrelevant as that bug appears to purely be an import issue. If you have any more information about this bug, please add it to the bug so that it is less confusing.
(In reply to Charles Rivet from comment #10) > (In reply to Peter Cigehn from comment #9) > > Adding back the depends_on_papyrus tag since this bug probably will need > > fixing in Papyrus to be able to show the element icon (which looks like an > > issue already in base Papyrus). Keep the tag until it a more detailed > > analysis have concluded that a work around can be made locally in Papyrus-RT. > > This seems to be the wrong way about. How can we depend on a Papyrus fix > when we don't even know yet that we will need a Papyrus fix? This is more > confusing than it should be. Okay, if that is confusing and you think that it doesn't add any information, then please remove the tag again. Personally I have found it *very* useful to be able to tag bugs that we know (with some probability) depends on Papyrus, but that we for some reason have not written a bug for yet (it could be lack of time, lack of competence in formulation a good Papyrus bug, more analysis needed by a Papyrus-RT developer to detail what the problem is in Papyrus) and I have used it for that purpose ever since we introduced this tag. But I don't have any strong opinion about it, and if you want it removed, then please do so again. > > Also, if we disregard the import aspect, this appears to be a (simple?) > sizing/spacing problem on creation. This bug also covers the use of the element icon, as indicated in the bullet list in Comment 0. And as indicated there: '1) The use of an element icon in the legacy tooling. This actually seem to be a general bug, since even if Papyrus do support the use of element icons, it does not seem to work. Even if the "Element icon" check-box on the Appearance tab in Papyrus-RT is checked, indicating that an element icon should be used, it does not seem to have any effect.' It was this finding that the "Element icon" check-box does not have any effect that made med add the depends_on_papyrus tag. This is an issue that you can see already in ordinary state machine diagrams in base Papyrus. > > Again, if we disregard the import aspect, the the "See also" to bug 497841 > would also be irrelevant as that bug appears to purely be an import issue. Keep in mind that the "See also" was added when this bug was created, when it indeed had an aspect of being import related. Bug 497841 was also related to aligning the size of elements in structure diagrams, which I found to be relevant for anyone fixing this bug. But if this is also found to be confusing, then please go ahead and remove it, now when we are not considering the import aspect. I still find that bug relevant since it is related to aligning sizes of elements (even if we disregard from the import aspect itself). > > If you have any more information about this bug, please add it to the bug so > that it is less confusing. Not sure what more can be added. If it was the aspect of the element icon that you felt was missing, then it was already there in bullet 1 in the bullet list in Comment 0.
(In reply to Peter Cigehn from comment #11) > (In reply to Charles Rivet from comment #10) > > (In reply to Peter Cigehn from comment #9) > > > Adding back the depends_on_papyrus tag since this bug probably will need > > > fixing in Papyrus to be able to show the element icon (which looks like an > > > issue already in base Papyrus). Keep the tag until it a more detailed > > > analysis have concluded that a work around can be made locally in Papyrus-RT. > > > > This seems to be the wrong way about. How can we depend on a Papyrus fix > > when we don't even know yet that we will need a Papyrus fix? This is more > > confusing than it should be. > > Okay, if that is confusing and you think that it doesn't add any > information, then please remove the tag again. Personally I have found it > *very* useful to be able to tag bugs that we know (with some probability) > depends on Papyrus, but that we for some reason have not written a bug for > yet (it could be lack of time, lack of competence in formulation a good > Papyrus bug, more analysis needed by a Papyrus-RT developer to detail what > the problem is in Papyrus) and I have used it for that purpose ever since we > introduced this tag. But I don't have any strong opinion about it, and if > you want it removed, then please do so again. I went your way and updated the bug guidelines (https://wiki.eclipse.org/Papyrus-RT/Bug_Guidelines) to your needs. Juse easier as you already have the process in hand! > > > > > Also, if we disregard the import aspect, this appears to be a (simple?) > > sizing/spacing problem on creation. > > This bug also covers the use of the element icon, as indicated in the bullet > list in Comment 0. And as indicated there: > > '1) The use of an element icon in the legacy tooling. This actually seem to > be a general bug, since even if Papyrus do support the use of element icons, > it does not seem to work. Even if the "Element icon" check-box on the > Appearance tab in Papyrus-RT is checked, indicating that an element icon > should be used, it does not seem to have any effect.' > > It was this finding that the "Element icon" check-box does not have any > effect that made med add the depends_on_papyrus tag. This is an issue that > you can see already in ordinary state machine diagrams in base Papyrus. > > > > > Again, if we disregard the import aspect, the the "See also" to bug 497841 > > would also be irrelevant as that bug appears to purely be an import issue. > > Keep in mind that the "See also" was added when this bug was created, when > it indeed had an aspect of being import related. Bug 497841 was also related > to aligning the size of elements in structure diagrams, which I found to be > relevant for anyone fixing this bug. But if this is also found to be > confusing, then please go ahead and remove it, now when we are not > considering the import aspect. I still find that bug relevant since it is > related to aligning sizes of elements (even if we disregard from the import > aspect itself). > > > > > If you have any more information about this bug, please add it to the bug so > > that it is less confusing. > > Not sure what more can be added. If it was the aspect of the element icon > that you felt was missing, then it was already there in bullet 1 in the > bullet list in Comment 0. OK. Thank you!
Added Papyrus bug to handled the state machine name issue, linked to this bug.
I am bit unsure about moving this to Future. Since changing the default size of states post-1.0 will have some impact on the layout of existing diagrams, it would be really nice to get this fixed for Papyrus-RT only. Maybe it is as simple to have some additional CSS rules for the margin (the element icon though might be harder to get fixed though). So if we do not want to "mess up" state machine diagram created with 1.0 at a later point in time, it feels like it would be good to get, at least part of, this bug fixed already for 1.0. Cannot really judge how big impact and how "annoyed" any 1.0 user will be if the layout is changed too much some time after 1.0.
