Create UI to create and edit message views
Currently we can only visualize existing message views in the tool. Create a UI that allows the creation and editing of message views (includes visualization).
Maybe the existing visualization needs to be replaced.
A starting point is the ClassNameHandler that already shows the option "Message View" in the options. The idea is to create a message view for the selected operation, if it doesn't exist. Then display it.
The best (at least in the future) would be a split view (see issue #24) that allows to display the structure and the current message view at the same time.
Comments (71)
-
-
reporter Messages should be created by dragging from one lifeline to another. Message order is very important and might follow a layout in the GUI.
One idea, I believe, was to click on a position on one lifeline and then drag to another and release (with only a straight line).
The other was to select one lifeline and then click on the other lifeline, which would then create a message between the two.
Tapping and holding should create a new lifeline. Possible objects from which the lifeline can originate should be among those that are visible to objects that exist in the messageView already, either because there is already a relationship between the classes or because an object was passed as a parameter to an object.
We use EMFs edit framework to get those possible values. It is the classes inside ca.mcgill.sel.ram.edit. In there I already modified some property descriptors. There is a class called
AdapterFactoryUtil
inca.mcgill.sel.ram.controller
(.edit package, the method is calledgetChoiceOfValuesFor(...)
). However, you can probably just reuse theSelectorView
. -
reporter References issue
#66.Added MessageViewController that can create messages and lifelines. The lifeline and message are "empty", i.e., the lifeline has no represents and the message no signature set yet. This then can be performed by the user through the UI.
→ <<cset ca330676cf91>>
-
reporter References issue
#66.Added generic createMove command method to BaseController to move any EObject to a new position.
→ <<cset 3dd9342d395f>>
-
reporter References issue
#66.Added moveLifeline to MessageViewController to allow moving of lifelines.
→ <<cset 28977855a7ab>>
-
reporter References issue
#66.Added creation of LayoutElement to createMessageView for first lifeline. The current location is (0, 0). Even if it will not be possible to move it, it is good to have a LayoutElement to be able to handle all lifelines the same way, e.g., when loading an existing message view.
→ <<cset a7074eccb28f>>
-
reporter -
assigned issue to
-
assigned issue to
-
reporter - changed milestone to AOSD 2014 Demo
-
reporter References issue
#66: Changed bound on type T of RelationshipView and RamEnd to allow model classes that are not a NamedElement. As far as I remember, this used to be required to be able to get a name for the end, however, now the TextView can do this through EMFEditUtil.For message views, the end should be the MessageEnd, which is not a NamedElement.
→ <<cset b168dad45ee0>>
-
reporter References issue
#66: Added MessageViewView and LifelineView including handler for LifelineView. Lifeline can already be dragged.→ <<cset ddd7c5e1b4ad>>
-
reporter References issue
#66: Added unistroke processor that can be locked to a certain axis.→ <<cset c406f715db59>>
-
reporter References issue
#66: Added eventContainer to LifelineView for message ends on the lifeline. It is a ContainerComponent so that it has an input overlay and is able to process several events.It can receive unistroke events in order to create a new message from there.
→ <<cset 9a0b7c7c1d67>>
-
reporter References issue
#66: Improved input handling on lifeline. No internal handler necessary. Events are forwarded to LifelineViewHandler, who needs to pass them along if necessary.→ <<cset 6ed99223501d>>
-
reporter References issue
#66: Added handler for MessageViewView. It can process unistroke events and draws the visualization to its unistroke layer. Furthermore, it founds out which lifeline views are affected by the start and end point.→ <<cset 090325ead5b8>>
-
reporter References issue
#66: Added message creation to MessageViewView. MessageCallView (name conflict with MessageView model class) is a RelationshipView for displaying message calls.→ <<cset 98492a3fa302>>
-
reporter References issue
#66: Changed LifelineView once again. EventContainer is not a ContainerComponent anymore. There are spacers for in between messages (to support unistroke events) and the actual fragments on the lifeline will have their own processors.→ <<cset c91810bd2e84>>
-
reporter References issue
#66: Added messages and the ability to have them automatically position depending on their ends. The receive event will adjust the height of the spacer above to be at the same level as the send event. The gate will do the same.→ <<cset e12b5624d144>>
-
reporter References issue
#66: Moved handling of message ends to LifelineView. MessageEndView will forward call to lifeline view, because the lifeline view knows its internals, the message end view is just a child.→ <<cset 25c064c443b7>>
-
reporter References issue
#66: Added drawing of arrow and positioning of signature.The message ends location needs to be at the middle of the component. Setting the anchor of a component to center somehow breaks the position of the component (it will show up slightly off).
Removed stroke and fill for debugging components.
→ <<cset 905a53b675d2>>
-
reporter References issue
#66: Added command-based creation of Lifelines. Setting of layoutelement moved to build method, because the notification for it will come after the creation of a new lifeline.→ <<cset 97ef79eb98e9>>
-
reporter References issue
#66:- Lifeline is positioned properly after creation.
- Added tap processor to name field to be able to change "represents" when it is not set yet (i.e., it can only be set once).
→ <<cset 58a5912e60e9>>
-
reporter References issue
#66: Added support for self messages to properly visualize them. Currently,RelationshipView
does not support drawing self references for any view, it does it specifically for classes (see issue #109).→ <<cset 401ee3e7a915>>
-
reporter References issue
#66: Fixed bug when creating a message: Created a self message instead of using the to lifeline.→ <<cset 17fbe3579023>>
-
reporter References issue
#66: Fixed problem: When a message without a signature is created, the changelistener of MessageItemProvider failed with a NPE, because the operation is null.→ <<cset 15f0309b800f>>
-
reporter References issue
#66: Message ends can now be deleted. Furthermore, only one spacer is added at the top. Then, whenever a new end is added a new spacer is added after. Depending on whether it is a receive event, it will be possible to create messages on it.→ <<cset d586815c95bc>>
-
reporter References issue
#66: New lifelines can be created:- the initial position is corrected by the handler now
- after creation, a selector will request to choose a lifeline instance
- an empty message is then created
→ <<cset df1847a460bf>>
-
reporter References issue
#66: Allow creation after sending a message where the operation returns void (no reply message).→ <<cset 0638fbb9f78e>>
-
reporter References issue
#66:- MessageCallView is positioned a bit more to the left to not interfer with spacers.
- messages can be added not only at the end
→ <<cset f8eb15cda72a>>
-
reporter References issue
#66: Layouting of messages is done by MessageViewView for the overall message view. Required to always make sure that everything is sequential and behaviour moves downwards properly.→ <<cset 50140f001662>>
-
reporter References issue
#66: Self messages are drawn properly again.→ <<cset b7aae129872f>>
-
reporter References issue
#66:- reply message return is placed properly
- arrow is only different for reply messages
→ <<cset 71025479a311>>
-
reporter References issue
#66: Added the ability to display create messages properly.The end view for the receive event of the create message is the LifelineView itself. Therefore, it needs to implement IRelationshipEndView.
When layouting messages the lifeline will be moved down according to the height of the name box such that the message can be placed in the center of it.
→ <<cset 8c414f2c3064>>
-
reporter References issue
#66: Combined handling of relationship ends for message ends and lifelines (create messages).→ <<cset 0a9a52741120>>
-
reporter References issue
#66: Moved to using line style of relationship view.→ <<cset edfbf7de3f61>>
-
reporter References issue
#66: Added proper display of lifeline for metaclasses. The full label will not contain "<<metaclass>>" in order to be able add an additional text on the top.Also adjusted the old LifelineView to display it properly.
→ <<cset 30de5d93ef0a>>
-
reporter References issue
#66: When the to lifeline doesn't exist yet, the next index needs to be + 2 from the fragment index of the from lifeline.getSpacerForFragmentAt also needs to consider lifelines with create messages.
→ <<cset 2ff56004ee1e>>
-
reporter References issue
#66: Added method to create a lifeline with a first message call at the same time.To create a message command, a reply message is created at the same time if the operation doesn't return void.
The send and receive event need to be added as a collection, because when using separate add commands, the one with index + 2 will not be executable. At that point, the first event hasn't been created yet.
→ <<cset d2fff8746805>>
-
reporter References issue
#66: Updated property descriptors to obtain proper choice of values.- represents for lifelines: If there is a message the caller is taken into consideration to find out all possible lifelines. This includes the association ends, passed parameters from a receiving call, local properties and classifiers with static operations.
- message siganture: if there is a receive event the type of the lifeline representer is used to obtain all valid operations that can be called.
→ <<cset d0b46a44c25d>>
-
reporter References issue
#66: The GateView needs to change its position also when the opposite is lower.When updating the layout, a fragment might not have the covered lifeline set. This happens when a message and its reply are added, but the fragments were added first. The command for the second message will be executed later.
→ <<cset 1a992655b5f5>>
-
reporter References issue
#66: Fix for removing the registerd listeners:When the MessageView is deleted, it is already removed from the aspect. Therefore, the adapter factory cannot be found, because the root container is not the aspect anymore. Unfortunately, this also applies to all other elements, such as lifelines, messages etc. There needs to be a better solution for this.
→ <<cset 996f3536186a>>
-
reporter References issue
#66: Hide the return text view if the operation returns void.→ <<cset ee845bb0851e>>
-
reporter References issue
#66: Changed way creating a lifeline and message works:In order to use the property descriptors for choice of values, a temporary lifeline and message is created. Then, represents for the lifeline is chosen, directly followed by the message that can be called on that specific type. Before the controller is called, all temporary objects are removed.
→ <<cset 02eb699c1739>>
-
reporter References issue
#66: When the previous fragment is not a receive event, the actual last fragment before needs to be found. Currently, all fragments after are checked whether they are on the same lifeline. I.e., the index of the next event on the same lifeline is taken.→ <<cset 93485b57602f>>
-
reporter References issue
#66: Small improvements for layouting message views:- wait to layout when the reply message is removed for the removal of the call message
- make sure the spacer height doesn't go below the required minimum
- ignore messages that were already removed, but their message ends still are part of the interaction
→ <<cset be9789ed55ec>>
-
reporter References issue
#66:- added creation of messages between two existing lifelines
- in case the end position at the existing to lifeline is the very beginning, the fragment before won't be found: For that case getIndexAfter is necessary as well
→ <<cset 3938d2d9e52c>>
-
reporter References issue
#66: Added support for create messages.A create message is created if there exists a static method with the name "create". In that case, a local property is created on the caller lifeline, which stores the return of the create call.
Messages can be created after that message on the same lifeline.
→ <<cset 00f1ec92520a>>
-
reporter References issue
#66: Added support to create self messages. A small line has to be drawn on the same lifeline.→ <<cset 5329b2f7abfb>>
-
reporter References issue
#66: Added separate text views for message call.Parameters can now be chosen. Either an existing parameter or feature or create a literal.
→ <<cset 48d53a168bac>>
-
reporter References issue
#66: Added commands for creation of values of parameter value mappings.→ <<cset 2471eaac4722>>
-
reporter References issue
#66: Implemented getText in order to be able to get default text for a parameter value mapping.→ <<cset 0275dc654806>>
-
reporter References issue
#66: Activated notifications for assignTo.→ <<cset 6ac37c1ddc0a>>
-
reporter References issue
#66: Filtered out an already set structural feature for assignTo.→ <<cset e2613cc7320a>>
-
reporter References issue
#66: Added creation of temporary property to be set as the assignTo of a message call.→ <<cset 7b9491a1cc27>>
-
reporter References issue
#66: Added handler for assignTo:- default selector with valid choice of values
- in case a temporary property is required a plus button can be pressed, which will lead to a new temporary property
→ <<cset 1c39b8c1a89d>>
-
reporter References issue
#66: Disabled dragging for message ends.→ <<cset 4c87c60c92dc>>
-
reporter References issue
#66: MessageViewController improved:- preventing reply messages for message calls on implementation classes and self messages
- the temporary property for the assignment is named after the operation called, excluding "get"
→ <<cset 45780349d30c>>
-
reporter References issue
#66: Improved message end allow message creation: messages cannot be created on lifelines of implementation classes. This means, that on the calling lifeline a message creation is allowed after.→ <<cset a9859d321d1a>>
-
reporter References issue
#66: When there is a call before, but no event follows, the index must be incremented by 2 instead.→ <<cset 50c31d00b5b2>>
-
reporter References issue
#66: Fixed spacer layouting according to new layout system.→ <<cset 31697c18145c>>
-
reporter References issue
#66: Added missing closeSelector methods and added rolling back of temporary state.→ <<cset 631f358fa1e9>>
-
reporter References issue
#66: Messages that go from right to left, need the signature view on the side of the opposite end.→ <<cset 3a8d7d9ad3f7>>
-
reporter References issue
#66: Added missing creation of reference for metaclasses.→ <<cset c0fcc1590785>>
-
reporter References issue
#66: Further improvements:- if the parameter of the parameter value mapping is a primitive type, show attributes of the classifier as well
- if an operation is called "get" when creating a temporary assignment property, an index out of bound was thrown: Use the return type name in that case.
- when selecting a lifeline or a message, all classifiers from lower level aspects that are mapped to the receiving classifier are taken into consideration as well
→ <<cset 3125a078f821>>
-
reporter References issue
#66: Return text view temporarily disabled until the return can be selected/created.→ <<cset ee97c03d6e79>>
-
reporter References issue
#66: Fixed problem where messages could be created after a reply message.→ <<cset 41508a2d2d3d>>
-
reporter References issue
#66: Fixed problem where the temporary events weren't removed from the lifelines coveredBy.→ <<cset d3848408a58d>>
-
reporter References issue
#66: Temporarily hiding reply text views.→ <<cset 42bdde8419c8>>
-
reporter - changed status to open
Current limitations:
- Returns cannot be specified
- When undoing it is possible that when an object is deleted, that unregistering as a listener won't work, because the object was removed and getting the container will not result in the aspect, which means that a new adapter factory is created
- changing the structural view likely will cause problems when dealing with message views
- messages cannot be deleted right now
- create messages are not properly visualized/created in the model
-
reporter References issue
#66: Added possibility to delete messages. The signature of the MessageCallView allows to be tap-and-hold and shows the option to delete.When deleting a message, all subsequent fragments followed by the selected call are also deleted. Everything (including the messages) needs to be deleted in reverse order, as would happen when undoing the creation of a new message.
In case a lifeline then does not contain any more fragments it is deleted.
→ <<cset 7de953a0b52b>>
-
reporter - changed status to resolved
-
reporter Continued in issue
#131. - Log in to comment
GUI implementation meeting notes
Lifelines should be moveable and extendable so that they can be organized vertically to be more understandable and take up less space.
Lifelines could still follow a layout, if needed.
Tapping and holding should create a new lifeline. Possible objects from which the lifeline can originate should be among those that are visible to objects that exist in the messageView already, either because there is already a relationship between the classes or because an object was passed as a parameter to an object.
Messages should be created by dragging from one lifeline to another. Message order is very important and might follow a layout in the GUI.
Messages should be calls of public methods of the destination lifeline's object.
Return messages can be created by tapping and holding a target lifeline. A return will then be displayed coming from the destination lifeline of the last message above orginating from the target lifeline.
Further Implementation Nesting messageViews create messages destroy messages loop, alt, option fragments