Community
Participate
Working Groups
The new child menu for the UML-RT DSML should provide a context menu in the model explorer for the creation of new child elements. Only the relevant UML-RT elements according to the constraints of the language shall be available. The menu shall also contain relevant parts from base UML that is also applicable to the UML-RT DSML to avoid that the user needs to use two separate menus when doing basic UML-RT modeling. The menu choices shall only be available if the corresponding UML-RT profiles are applied, i.e. base UML-RT profile for structuring modeling and the UML-RT state machine profile for behavior modeling. Menu choices to be available at different elements. Please note that this list is not necessarily exhaustive, but only a first proposal for the most fundamental elements for basic UML-RT modeling. Items marked with * should only be availble when the UML-RT state machine profile is applied. Model/Package Package Capsule Capsule Part Port Attribute Operation State Machine * Class (Same child elements as Class on Model/Package level) Enumeration (Same child elements as Enumeration on Model/Package level) Protocol Out Protocol Message Parameter In Protocol Message Parameter InOut Protocol Message Parameter Class Attribute Operation State Machine * Class (Same child elements as Class on Model/Package level) Enumeration (Same child elements as Enumeration on Model/Package level) Enumeration Enumeration Literal It must be considered that the UML-RT DSML will be used in contexts of normal UML modeling, e.g. when doing system documentation models where UML-RT structure modeling will be combined with use case modeling, activity modeling, ordinary class modeling and so on.
New Gerrit change created: https://git.eclipse.org/r/52074
Gerrit change https://git.eclipse.org/r/52074 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=16fa858f23918710f2c9eae224dae5065435330f
This gerrit has been merged. A second commit updated the menu in order to reorder alphabetically.
I've looked at the new child menu for UML-RT. In general it looks like too many menu choices are incorrectly available on the different levels and for the different parent elements. Here are the incorrect menu choices I have found: Package/Model Enumeration Literal Capsule Protocol Class CapsulePart Protocol Port Enumeration Attribute CapsulePart Operation ProtocolMessage OUT ProtocolMessage INOUT ProtocolMessage IN Should this Bugzilla på reopened and the superfluous/incorrect menu choices be handled within the scope of this Bugzilla or should that be covered by some new "filtering" Bugzilla?
I am for some reason unable to reopen this Bugzilla. Can someone with access rights reopen this one so that we can keep track of ensuring that only valid menu choices are displayed? This Bugzilla is partly overlapping with Bug 46458, which I suggest can be closed since it originally had a much smaller scope than what this Bugzilla have.
(In reply to Peter Cigéhn from comment #5) > I am for some reason unable to reopen this Bugzilla. Can someone with access > rights reopen this one so that we can keep track of ensuring that only valid > menu choices are displayed? This Bugzilla is partly overlapping with Bug > 46458, which I suggest can be closed since it originally had a much smaller > scope than what this Bugzilla have. I reopen it, but I will create some subtasks that describes the issues from a dev point of view. This one will be closed again as soon as all subtasks are closed
(In reply to Remi Schnekenburger from comment #6) > I reopen it, but I will create some subtasks that describes the issues from > a dev point of view. This one will be closed again as soon as all subtasks > are closed That sounds good! Thanks Remi.
I realized that we still are missing the new child menu choice for creating a parameter for a protocol message (see the original proposal in Comment 0, where each of the three different kinds of protocol messages have Parameter menu choice). Currently it is not possible to create a parameter of protocol message, neither using the standard New Child menu, nor the UMLRealTime new child menu, since none of them is available when right clicking on a protocol message. I have written Bug 479635 to track that specific case.
Bug 475709 fixed, protocol can be created only on Packages and Models, not on Classifiers.
I've checked the latest Papyrus-RT build regarding the new child menu. And indeed, the possibility of creating Protocols as described in Bug 475709 has been fixed. It is now only possible to create Protocols contained in Packages (and Models). It also looked like Bug 475712 have been (implicitly?) fixed. I did not seem to be able to create Capsule Parts anywhere else than in Capsules as you would expect. It looks like Bug 475711 is also fixed. I did not seem to be abel to create Protocol Messages anywhere else than in a Protocol. The earlier case with lots of incorrect menu choices for an Enumeration seem to fixed, since you can only create an Enumeration Literal (as expected). So we seem to be getting there. I have some feedback though: 1) The general principle that the menu choices are sorted alphabetically, is that a basic principle in Papyrus? Or can we can define any order we like, and also have separators? Personally I was thinking in line with having them grouped in some natural order, e.g. related to how common they are being used. In my proposal in Comment 0 I actually listed them in the order I was expecting them on the menus. They could actually also be grouped even further with separators. For example: The menu for Capsule could look like this: Capsule Part Port --------- Attribute Operation ---------- State Machine ---------- Class Enumeration I would expect the case with nested classes and enumerations within a capsule to be much more seldom, then capsule parts and ports, and thus they should be further down the menu. Personally I find it easier to find things with groupings and ordering like this, than having it in strict alphabetical order. Yes, if there are *a lot* of menu choices (like on the standard New Child menu), then it makes more sense to have them alphabetically. Any comments or counter arguments for keeping it in alphabetical order, instead of grouping them like this? 2) I discovered that there was a UMLRealTime menu of a Capsule Part where you could create Attribute, Capsule Part and Port. At first I did not know what to expect, but when trying them the creation was made under the capsule typing the capsule part (which kind of made sense). But still this is rather confusing and can be very error prone. I would suggest that the UMLRealTime menu currently available for Capsule Part shall be removed. I guess we should have a separate Bugzilla for that.
For the Bug 475712 and Bug 475711, element type configuration model is fixed, but as soon as the tests are not yet implemented, we did not close these bugs. Onder is working on the tests currently. For the grouping, the easiest thing for a user is to find by name when he is not used to the tool. In this case, the best way is to sort the menu by alphabetical order. The order is decided in the model new child.xmi, so any order can be given for the elements. The users could create their own new menu corresponding to their usage (simplified menu or changed content). For the separators, that would be a nice feature to add in the new child menu. They are not supported yet. For the CapsulePart new child menu, we had a (very) long discussion yesterday with Patrick, about part creation in the composite diagram. There are several ways to proceed for the creation of property in the composite structure diagram. I will ask him to create a bug on Papyrus to discuss that topic, if not done yet.
(In reply to Remi Schnekenburger from comment #11) > For the CapsulePart new child menu, we had a (very) long discussion > yesterday with Patrick, about part creation in the composite diagram. There > are several ways to proceed for the creation of property in the composite > structure diagram. I will ask him to create a bug on Papyrus to discuss that > topic, if not done yet. Yes, I have seen the discussion in some Bugzillas going on related to this in base UML and in SysML. One thing that differs for the UML-RT DSML is that we (at least in the normal case) want to stay away from the complexity of nested structure diagrams, i.e. this about letting parts have structure compartment which can show the internal structure of that part (which in its turn can show the internal structure of any of its part), since this is known to cause a lot of complexity and clutter. As indicated in Bug 476951 we shall not show the structure compartment for capsule parts (instead we shall focus on providing a quick double-click navigation on a capsule part to navigate to its capsule's structure diagram). So even if we want to support this for base UML and for SysML, I still think that we shall restrict this for UML-RT DSML. At least we shall prohibit the creation of internal stuff, like attributes and capsule parts. Attributes and capsule parts should only be allowed to be created in the context of the capsule itself, not through any capsule part being typed by the capsule. When it comes to ports however, that could be different. At least for external behavior ports. Since we are going to support drag-and-drop of a protocol onto the border of capsule part, which then should create an (external behavior) port on the capsule typing the capsule part (and of course then also show this port on the border of the capsule part and all other capsule parts being typed by the same capsule), we could support creating a port on a capsule part (and thus implicitly in the capsule) also using the UMLRealTime new child menu. At least start with removing the possibility of creating attribute and capsule part from the UMLRealTime new child menu for a capsule part.
Gerrit change https://git.eclipse.org/r/61548 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=3dfe68189c5d6392e838e49dc62b6fd8308d51ce
I tested the latest Papyrus-RT build with the latest Gerrit change. And it looks like something went wrong in general with the context menu in the model explorer. If I right click on a normal UML model, then it seem to work fine. The context menu looks as it use to. If I then apply the UML-RT profile, then the context menu only have four unlabeled sub-menu-choices. There is some random behavior also where the sub-menus are sometimes possible to open, and sometimes not. And when you are able to open them, they also have unlabeled menu-choices.
(In reply to Peter Cigehn from comment #14) > I tested the latest Papyrus-RT build with the latest Gerrit change. And it > looks like something went wrong in general with the context menu in the > model explorer. > > If I right click on a normal UML model, then it seem to work fine. The > context menu looks as it use to. If I then apply the UML-RT profile, then > the context menu only have four unlabeled sub-menu-choices. There is some > random behavior also where the sub-menus are sometimes possible to open, and > sometimes not. And when you are able to open them, they also have unlabeled > menu-choices. It seems that there are some null pointers or some errors in the building of the menu, which causes the disparition of many elements in the model explorer. I don't have them in my environment, can you attach the error log you have?
(In reply to Remi Schnekenburger from comment #15) > It seems that there are some null pointers or some errors in the building of > the menu, which causes the disparition of many elements in the model > explorer. I don't have them in my environment, can you attach the error log > you have? Here is the error in the error log. It gets logged each time you open the (empty) context menu: eclipse.buildId=4.5.1.M20150904-0015 java.version=1.8.0_66 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US Framework arguments: -pluginCustomization C:\Users\cigehpet\eclipse\papyrusrt-nightly\eclipse\plugin_customization.ini -pluginCustomization C:\Users\cigehpet\eclipse\papyrusrt-nightly\eclipse\plugin_customization.ini Command-line arguments: -os win32 -ws win32 -arch x86_64 -pluginCustomization C:\Users\cigehpet\eclipse\papyrusrt-nightly\eclipse\plugin_customization.ini -data C:\Users\cigehpet\eclipse\papyrusrt-nightly\workspaces\ws6 -pluginCustomization C:\Users\cigehpet\eclipse\papyrusrt-nightly\eclipse\plugin_customization.ini org.eclipse.ui Error Mon Nov 30 14:56:32 CET 2015 Unhandled event loop exception java.lang.UnsupportedOperationException at org.eclipse.papyrusrt.umlrt.tooling.filter.elementtypefilter.impl.ParentMatcherFilterImpl.matches(ParentMatcherFilterImpl.java:194) at org.eclipse.papyrus.infra.filters.internal.operations.CompoundFilterOperations.matches(CompoundFilterOperations.java:97) at org.eclipse.papyrus.infra.filters.impl.CompoundFilterImpl.matches(CompoundFilterImpl.java:391) at org.eclipse.papyrus.infra.newchild.CreationMenuFactory.filterMatches(CreationMenuFactory.java:157) at org.eclipse.papyrus.infra.newchild.CreationMenuFactory.populateMenu(CreationMenuFactory.java:109) at org.eclipse.papyrus.views.modelexplorer.newchild.ModelExplorerDynamicNewChild.fill(ModelExplorerDynamicNewChild.java:72) at org.eclipse.ui.internal.menus.DynamicMenuContributionItem.fill(DynamicMenuContributionItem.java:208) at org.eclipse.jface.action.MenuManager.doItemFill(MenuManager.java:724) at org.eclipse.jface.action.MenuManager.update(MenuManager.java:806) at org.eclipse.jface.action.MenuManager.handleAboutToShow(MenuManager.java:468) at org.eclipse.jface.action.MenuManager.access$1(MenuManager.java:461) at org.eclipse.jface.action.MenuManager$2.menuShown(MenuManager.java:493) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:255) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4362) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1113) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1137) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1118) at org.eclipse.swt.widgets.Control.WM_INITMENUPOPUP(Control.java:5037) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4705) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:339) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1633) at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2117) at org.eclipse.swt.widgets.Display.windowProc(Display.java:5050) at org.eclipse.swt.internal.win32.OS.TrackPopupMenu(Native Method) at org.eclipse.swt.widgets.Menu._setVisible(Menu.java:262) at org.eclipse.swt.widgets.Display.runPopups(Display.java:4221) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3763) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608) at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
Ok, I see. My bad, I did not push the full code on the server. I will update it before this evening, I'll let you know when it is finished.
I checked the latest build, and now the context menu works again as expected! The menu is filtered when right clicking on a capsule part, and only port is available. This looks good. I saw that the order of the menu choices for a capsule had been changed, to the proposal I made in Comment 10, about having them in an order with the most common cases on the top and the more uncommon at the bottom (still miss the separators though... :-) If we are going to do this arrangement of importance/commonality order (and not have them just strictly alphabetical as it has been before), I wonder if we should look through the order for the other parent elements as well, e.g. on package/mode level, I would propose to have it like this: Package -------- Capsule Protocol ------- Class Enumeration But before looking into the order of other parent elements, I would just like to check which principle we should try to follow? Strictly alphabetical only, or to actually allow some importance/commonality ordering (including grouping) as has been changed for the capsule?
(In reply to Peter Cigehn from comment #18) > I checked the latest build, and now the context menu works again as > expected! The menu is filtered when right clicking on a capsule part, and > only port is available. This looks good. > > I saw that the order of the menu choices for a capsule had been changed, to > the proposal I made in Comment 10, about having them in an order with the > most common cases on the top and the more uncommon at the bottom (still miss > the separators though... :-) > > If we are going to do this arrangement of importance/commonality order (and > not have them just strictly alphabetical as it has been before), I wonder if > we should look through the order for the other parent elements as well, e.g. > on package/mode level, I would propose to have it like this: > > Package > -------- > Capsule > Protocol > ------- > Class > Enumeration > > But before looking into the order of other parent elements, I would just > like to check which principle we should try to follow? Strictly alphabetical > only, or to actually allow some importance/commonality ordering (including > grouping) as has been changed for the capsule? For the order, we chose to go to alphabetical, as this is the most user friendly on long menus. In the case of Papyrus-RT, it's not a technical problem to modify the order. I would personnaly keep the alphabetical order, because i find it easier to find the elements always ordered in the same way (class after attribute, before model, etc.). As long as the grouping of elements is not possible (a enhancement proposal for Neon?), I would prefer to stick to the neutral order. As a side note, we currently only have one list of menu elements for UML-RT. So we will have to split the definition of the menu if we have a different order for different elements. That's not a problem, playing with filters, but it can increase the maintenance costs a bit.
Created attachment 258380 [details] Screen shot showing the UMLRealTime new child menu for a capsule (In reply to Remi Schnekenburger from comment #19) > For the order, we chose to go to alphabetical, as this is the most user > friendly on long menus. In the case of Papyrus-RT, it's not a technical > problem to modify the order. I would personnaly keep the alphabetical order, > because i find it easier to find the elements always ordered in the same way > (class after attribute, before model, etc.). As long as the grouping of > elements is not possible (a enhancement proposal for Neon?), I would prefer > to stick to the neutral order. Okay, that was I thought your opinion was from before as well. But then I get a bit confused since I can see that the order for the capsule is exactly in the order I proposed in Comment 0. See the attached screen shot. Is it by accident that this order is shown now (exactly as I had proposed), and not something that you have made on purpose? Should it then be reverted to alphabetical order, or? > > As a side note, we currently only have one list of menu elements for UML-RT. > So we will have to split the definition of the menu if we have a different > order for different elements. That's not a problem, playing with filters, > but it can increase the maintenance costs a bit. I am not sure I fully understand the issue, but I have a feeling that we do not want fundamentally different order for different model elements. Take the order of the menu items for a capsule vs. a class as an example (see Comment 0). As you can see the proposal, it is the same order, apart from that Capsule Part and Port is not available for Class. But the other common menu choices are in the same order. So *if* we go for a defined order, then I assume that we keep the order the same for similar kind of model elements. So I hope that we should have to make it more complex than needed, even if we make the menus ordered/grouped.
To my understanding this Bugzilla is basically done. All menu choices mentioned in Comment 0 are available. We have one additional menu choice left, which is tracked by Bug 479635. The only aspect left is that since we do not yet have the menu separator we shall group/order the menu choices, but stick to the simplest approach with alphabetical order as discussed in Comment 18 and forwards. I suggest that we break this aspect out into an own Bugzilla, i.e. ensure consistent alphabetical order on all sub menus. When we have gotten support for a menu separator (as proposed in Comment 18), then we can re-consider doing some natural grouping on the sub menus. Remi, do you agree? Can you make sure that we have a Bugzilla for the tracking of the menu separator (I think that you have a better understanding of formulating this one on Papyrus), as well as a Bugzilla for changing back to alphabetical order on the sub menu for the capsule? After that we can then close this one. Or do you see that we have anything more left to do withing the scope of this one (as originally stated in Comment 0)?
New Gerrit change created: https://git.eclipse.org/r/66501
Gerrit change https://git.eclipse.org/r/66501 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=bea2125e48df6d776fbfda1239cd58a21ea2aeb5
I checked the latest build of Papyrus-RT and now the alphabetical order of the menu choices for a capsule is back again. I say that we put this rather generic one into resolved/verified fixed and cover any remaining issues in more detailed Bugzillas.
Close as verified fixed.
