1. McGill CORE Avatar McGill CORE
  2. TouchCORE
  3. touchram
  4. Issues

Create UI to create and edit message views

Issue #66 resolved
Matthias Schoettle created an issue

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)

  1. James Thornton

    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

  2. Matthias Schoettle 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 in ca.mcgill.sel.ram.controller (.edit package, the method is called getChoiceOfValuesFor(...)). However, you can probably just reuse the SelectorView.

  3. Matthias Schoettle 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>>

  6. Matthias Schoettle 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>>

  9. Matthias Schoettle 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>>

  10. Matthias Schoettle reporter

    References issue #66: Added MessageViewView and LifelineView including handler for LifelineView. Lifeline can already be dragged.

    → <<cset ddd7c5e1b4ad>>

  12. Matthias Schoettle 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>>

  13. Matthias Schoettle 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>>

  14. Matthias Schoettle 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>>

  15. Matthias Schoettle 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>>

  16. Matthias Schoettle 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>>

  17. Matthias Schoettle 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>>

  18. Matthias Schoettle 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>>

  19. Matthias Schoettle 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>>

  20. Matthias Schoettle 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>>

  21. Matthias Schoettle 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>>

  22. Matthias Schoettle 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>>

  24. Matthias Schoettle 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>>

  25. Matthias Schoettle 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>>

  26. Matthias Schoettle 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>>

  28. Matthias Schoettle 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>>

  29. Matthias Schoettle 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>>

  32. Matthias Schoettle 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>>

  35. Matthias Schoettle 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>>

  36. Matthias Schoettle 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>>

  37. Matthias Schoettle 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>>

  38. Matthias Schoettle 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>>

  39. Matthias Schoettle 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>>

  40. Matthias Schoettle 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>>

  42. Matthias Schoettle 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>>

  43. Matthias Schoettle 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>>

  44. Matthias Schoettle 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>>

  45. Matthias Schoettle 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>>

  46. Matthias Schoettle 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>>

  48. Matthias Schoettle 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>>

  54. Matthias Schoettle 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>>

  56. Matthias Schoettle 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>>

  57. Matthias Schoettle 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>>

  63. Matthias Schoettle 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>>

  68. Matthias Schoettle 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
  69. Matthias Schoettle 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>>

  72. Log in to comment
Assignee
Type
task
Priority
major
Status
resolved
Component
GUI
Milestone
AOSD 2014 Demo
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!