Bug 502556 - [Tooling] Improve drag-an-drop in model explorer, including support for UML-RT protocols
Summary: [Tooling] Improve drag-an-drop in model explorer, including support for UML-R...
Status: UNCONFIRMED
Alias: None
Product: Papyrus-rt
Classification: Modeling
Component: tool (show other bugs)
Version: 0.7.2   Edit
Hardware: PC Windows 7
: P3 normal
Target Milestone: Future   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard: depends_on_papyrus
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-29 08:28 EDT by Peter Cigehn CLA
Modified: 2017-02-03 03:01 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Cigehn CLA 2016-09-29 08:28:36 EDT
When verifying Bug 497742 it was concluded that there were some additional corner case, see Bug 497742 Comment 18. Some of these cases seem to be general issues with base Papyrus, but could also be specifically related to Papyrus-RT, e.g. the specific aspects of drag-and-drop of protocols. This Bugzilla is a tracking Bugzilla for the specific aspects that needs to be addressed in Papyrus-RT. Any issues identified that needs improvement in Papyrus shall be made blocking this Bugzilla.

Here is the issues that was identified in Bug 497742 Comment 18:

1) Two protocols contained in the same package. Try to reorder them by moving the first one after the other, i.e. the "head" of the move indicator should be at the same nesting level as the protocol itself and not nested inside the protocol. Nothing happens when you do this. Sure, when the "head" indicator is nested inside the protocol nothing should happen since you cannot move a protocol inside another protocol. But when you have the "head" nested at the same level I would have expected that you did a re-order of the protocols in the same package.

After some more testing with 3 protocols in a package, it looks to be the border case when trying to drop and move the protocol last in the package. If you drop the first protocol after the second then you are able to reorder. But not dropping the first after the third (and last) protocol in the package.

2) Two protocols contained in the same package. If you drop the first protocol directly after itself, i.e. basically perform a "no-op" since you move to the position in the containing package that it already have, then the protocols change order. This actually seem to be also some general issue, because I can see the same kind of behavior for ordinary model elements, e.g. a class. But for classes the behavior with swapping order, when it shouldn't, happens "random". Sometimes it performs the swap (when it shouldn't) and sometimes it works as expected, i.e. nothing happens since the drop shouldn't change order. For protocols though it is consistently changing the order, even if there should be a "no-op".

3) If you have three protocols in a package and drop the the second protocol before itself, i.e. basically perform a "no-op" since dropping before itself should not change the order, then the second and third protocol in the package changes order.

As indicated in Bug 497742 Comment 19 here are some aspects that could be improved in base Papyrus for which additional Bugzillas on Papyrus can be written and made blocking this Bugzilla:

* is not extensible to support DSML-specific drag-and-drop needs
* assumes dropping into the eContainer, without regard for its own facet
  customizations of the tree structure
* does not account for the fact that a dropped object may not be contained
  in the same EReference as the one it is dropped next to