Community
Participate
Working Groups
Currently the properties view for the base UML parameter has lots of properties. Since a parameter of a protocol message has a very limited set of relevant properties, basically just the name and its type, a specific Real Time tab shall be provided for the case of protocol message parameter. Please note that this customization shall only be done for the case for a parameter owned by a protocol message. For normal parameters owned by operations for capsules and classes, a more complete set of properties shall be provided, possibly there is no need for a specific Real Time tab for properties for parameters owned by operations for capsule and classes. If there is a need to customize also that case, it must be different customizations made for the two different cases of protocol message parameters and ordinary operation parameters. For the protocol message parameter two properties shall be shown: * Name * Type Regarding the type, the selection of the type can divided into three cases: 1) The * case, which is special notion for an untyped parameter, i.e. the protocol message parameter can be used for passing along any kind of data. See Bug 479131 for the support for this in the code-generator. When selecting that the parameter's type is '*', then in practice the parameter is left untyped, i.e. the type is unset. 2) Primitive types from a model library. See Bug 478797 for the decision of which model library to use for primitive C++ types 3) A user defined type or any other available type Preferably a popup-menu, or drop-down menu, should be presented when the type is being selected, where either '*', all the primitive types from the relevant library with C++ primitive types, or a choice of selecting a any other type (using a standard search/browse dialog).
New Gerrit change created: https://git.eclipse.org/r/80737
Gerrit change https://git.eclipse.org/r/80737 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=da0ab47f680e16108345548a3f873ba98bf4e1b5
(In reply to Eclipse Genie from comment #2) > Gerrit change https://git.eclipse.org/r/80737 was merged to [master]. The UML-RT tab for message parameters now shows the name and type properties. The type property editing experience is the same as in the parameters table for a protocol message: the "..." button shows a pop-up menu with quick selections for "*" and the language-specific primitive types, plus options to browse existing types or create new types. (this reuses the same code as the parameters table)
I have checked the latest Papyrus-RT build and the protocol message parameter now have a UML-RT tab with name and type properties. Also checked that the parameter of an ordinary operation, owned by a capsule or class, does not have the UML-RT specific tab. One thing that I noted though was the '*' case, which when selected shows the text "<Undefined>" in the type field. It would be good to show '*' instead, in the corresponding way as being done in the parameter table for a protocol message for this case.
One more thing (which was not considered originally in Comment 0), is the completion support in the type field, similar to the content assist support that exist in the parameter table for a protocol message. Is it possible in some way to re-use this content assist support also for the type field for an individual protocol message parameter? I guess that this is something that needs to be supported in base Papyrus. Anyway, such an improvement probably should be tracked in a separate Bugzilla, but I just wanted to bring it up since we are working with this now. Especially if some refactoring is needed in base Papyrus. We already have a few Bugzillas related to improvements of the content assist support, as a result of the earlier work with the parameter table. And those improvements would of course be applicable here as well.
(In reply to Peter Cigehn from comment #4) > > One thing that I noted though was the '*' case, which when selected shows > the text "<Undefined>" in the type field. It would be good to show '*' > instead, in the corresponding way as being done in the parameter table for a > protocol message for this case. Oops, yes, of course this should use the same label provider as the table. (In reply to Peter Cigehn from comment #5) > One more thing (which was not considered originally in Comment 0), is the > completion support in the type field, similar to the content assist support > that exist in the parameter table for a protocol message. As you suggest, this is an issue of wider scope: the Papyrus framework for these reference widgets in the property sheet are not editable by the keyboard. It would be best to improve the reference widget in Papyrus to support (optionally) keyboard editing with completion proposals, which then can be used by Papyrus-RT for message parameter types and possibly also capsule-part and port types (although, those edits have greater impact on the structure). In any case, we would need this to apply also to properties of ordinary classes in Papyrus and in Papyrus-RT. So, yes, please raise a separate enhancement request that we can then block on an enhancement in Papyrus (hopefully for Neon.2).
(In reply to Christian W. Damus from comment #6) > > So, yes, please raise a separate enhancement request that we can then block > on an enhancement in Papyrus (hopefully for Neon.2). Actually, we already have in Papyrus a CompletionStyledTextReferenceDialog class that may be what we need for this use case. So, we could possibly short-circuit the additional enhancement bugzilla.
New Gerrit change created: https://git.eclipse.org/r/80834
(In reply to Eclipse Genie from comment #8) > New Gerrit change created: https://git.eclipse.org/r/80834 This adds support for the '*' notation for unspecified parameter types and also uses the core Papyrus property-sheet widget for keyboard-editable references by qualified name. Note that this makes two obvious visual changes: * the icon of the type is no longer presented because the text field used by the Papyrus framework does not support images * the qualified name of the referenced type is presented when necessary to correctly identify an element. This is as in the edit mode of the type cell in the parameters table of a message, but the text field in this case does not have an edit mode distinct from the basic display mode So, this is then quite different to the type field for ports and capsule-parts. What do you think, @Peter? A further note: I cannot verify that content-assist works in this type field because it doesn't seem to work on Mac platform at all: it doesn't work in the table, either, where reports from Windows users suggest that it does.
I tried the latest patch set. Not sure if I have some issues with my development environment, but I am unable to create new protocol message parameters using the UML-RT new child menu. But I was able to create one using the standard new child menu so I could test the new type field. But even in that case, the ... button and popup menu did not work. Disregarding what I selected, the type was not changed. When testing the content assist, one see the same issues as we already have identified in Bug 495157. Which in its turn gives the same kind of behavior as described in Bug 501119. Do you know if the content assist used here shares the same code as the content assist for the parameter table? Since we want to have the same behavior and improvements in both places, one can hope that it is the same code that is shared between them. And as you say, it would be good if it was a more clear distinction between "display mode" and "edit mode", e.g. if "display mode" shall display the fully qualified name, whereas "edit mode" should allow the user to only type the name (without qualified name). Another issue I could see was that the field always seem to get a red indicator, when you select a new paramter. If you click in the type field, and press enter, you get the green flash and then the type field becomes white again. I am not sure if it matters that this looks different that the type field of ports and capsule parts. But to make it more clear, I guess a field which have content assist should be annotated with the standard(?) "light bulb" to indicate that the field have content assist.
Forgot to mention that the issue in Bug 494815 also can be seen here regarding the <Undefined> at the top of the content assist proposals.
(In reply to Peter Cigehn from comment #10) > I tried the latest patch set. Not sure if I have some issues with my > development environment, but I am unable to create new protocol message > parameters using the UML-RT new child menu. But I was able to create one > using the standard new child menu so I could test the new type field. But > even in that case, the ... button and popup menu did not work. Disregarding > what I selected, the type was not changed. This is all very strange. I think I need to try the patch in a Windows VM, myself, as I don't see anything like this on Mac (except of course that on Mac the content-assist doesn't work; I wonder whether it's a conflict with the OS keybinding for Spotlight; in any case a Papyrus bug, not Papyrus-RT). The light bulb decoration is actually a good point. It is important to show that but, again, this needs to be fixed in Papyrus. Until all of the niceties of the content-assist field can be sorted out, I think I should just go with the previously read-only field with just a small improvement to present the null value as '*'.
(In reply to Christian W. Damus from comment #12) > (In reply to Peter Cigehn from comment #10) > > I tried the latest patch set. Not sure if I have some issues with my > > development environment, but I am unable to create new protocol message > > parameters using the UML-RT new child menu. But I was able to create one > > using the standard new child menu so I could test the new type field. But > > even in that case, the ... button and popup menu did not work. Disregarding > > what I selected, the type was not changed. > > This is all very strange. I think I need to try the patch in a Windows VM, > myself, as I don't see anything like this on Mac (except of course that on > Mac the content-assist doesn't work; I wonder whether it's a conflict with > the OS keybinding for Spotlight; in any case a Papyrus bug, not Papyrus-RT). I tried it again in my development environment, rebuilding everything. And now it worked... So it was probably something temporary in my development workspace! :) > > The light bulb decoration is actually a good point. It is important to show > that but, again, this needs to be fixed in Papyrus. > > Until all of the niceties of the content-assist field can be sorted out, I > think I should just go with the previously read-only field with just a small > improvement to present the null value as '*'. +1 Yes, I agree. The improvement with content assist in the type field is something that we can improve later.
(In reply to Peter Cigehn from comment #13) > > > > The light bulb decoration is actually a good point. It is important to show > > that but, again, this needs to be fixed in Papyrus. > > > > Until all of the niceties of the content-assist field can be sorted out, I > > think I should just go with the previously read-only field with just a small > > improvement to present the null value as '*'. > > +1 Yes, I agree. The improvement with content assist in the type field is > something that we can improve later. Good. It was a useful experiment to see what is already available in Papyrus, but I think it's not ready for this case, yet.
Gerrit change https://git.eclipse.org/r/80834 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=6001af5279ed3f5359f82bd682b4371297382456
(In reply to Eclipse Genie from comment #15) > Gerrit change https://git.eclipse.org/r/80834 was merged to [master]. The Type field now shows the asterisk for untyped protocol message parameters.
Verified in the latest Papyrus-RT build, that the untyped protocol message parameter case now is shown as *, i.e. aligned with * on the popup when selecting the type.
Closing as verified fixed.
