Add support to reorder messages and fragments

Issue #165 resolved
Matthias Schoettle created an issue

It should be easily possible to reorder messages and fragments in a message view. This includes changing the fragment container, i.e., moving a fragment into or out of a combined fragment.

For example, by dragging them to the new position.

Comments (17)

  1. Matthias Schoettle reporter

    Because fragments have a placeholder (on the lifeline) and an actual view, it seems quite simple to add drag support. Some example code for the original behaviour fragment:

    // Event occurs on the actual view (which is dragged around)
    @Override
    public boolean processDragEvent(DragEvent dragEvent) {
        // Allow dragging only on the Y axis.
        // Create single instance here instead to reuse.
        new DelayedDrag(5f, Axis.X).processGestureEvent(dragEvent);
    
        // In case the view needs to be moved back to its original position.
        if (dragEvent.getId() == MTGestureEvent.GESTURE_ENDED) {
            placeHolder.updateLayout();
        }
    
        return true;
    }
    

    For messages it could be a bit more difficult, because I am not sure if the message end on the lifeline can (should) be moved directly. But it might be enough to move the message (signature view) instead, which would also be better to see visually.

  2. Matthias Schoettle reporter

    References #165: Adds simple support to move a message up or down by one.

    Currently, simple messages can be moved within the interaction and they will not be moved above the initial message or below the reply message.

    Adds test cases that cover moving of messages within the interaction and bound tests.

    → <<cset ea63b944c7cd>>

  3. Matthias Schoettle reporter

    References #165: Adds moving messages support to the GUI.

    Currently, move notifications are translated to removal and re-adding. It would also be possible to add moving support to the UI where the view is just moved within its container.

    → <<cset c7308315d1de>>

  4. Matthias Schoettle reporter

    References #165: Adds boundary support.

    Determines lower and upper bound and ensures that messages are only moved within those boundaries.

    Nested Behaviour is not supported with this yet.

    → <<cset d953854c2352>>

  5. Matthias Schoettle reporter

    References #165: Adds support for nested behaviour.

    Updates retrieval of lower and upper boundary to take into consideration nested behaviour. Also, adds support for moving simple messages directly before/after messages with nested behaviour.

    → <<cset a3eb663df433>>

  6. Matthias Schoettle reporter

    References #165: Changes the order of moving fragments down.

    Moves both ends to the same index, in order to move other fragments up. This is in preparation to be able to move more fragments at the same time.

    → <<cset 449f70f4481c>>

  7. Matthias Schoettle reporter

    References #165: Adds support for moving one to many fragments at the same time.

    This helps support single fragments, but also complete nested behaviour.

    → <<cset 6f7b9d57e0e0>>

  8. Matthias Schoettle reporter

    References #165: Moves implementation of moveMessage to FragmentsController and renames to moveFragment.

    MessageController now just delegates to FragmentsController. Adds tests with fragments moving to FragmentsController.

    → <<cset c1bc21abd8a0>>

  9. Matthias Schoettle reporter

    Refactor: Changes handling of adding/removing of combined fragments, operands and their contents.

    When a combined fragment is added or removed, all its contents are explicitly added or removed as well. The fragment views are added or destroyed by the MessageViewView. I.e., destroying is not handled by the LifelineView anymore.

    This is more consistent across initial build up and handling of events. Also, it facilitates further improvements.

    Related issues:

    refs #165 refs #470

    → <<cset ad482df9fb2d>>

  10. Matthias Schoettle reporter

    References #165: Adds moving support to Combined Fragment.

    Possible due to changes of previous commit improving handling of adding/removal of combined fragment contents.

    → <<cset df18a317001d>>

  11. Log in to comment