Bugzilla – Full Text Bug Listing
| Summary: | [Navigator & Editor Sockets] Drag and drop tree-item/element from file A to file B got problem | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Automotive] Sphinx | Reporter: | nguyenntk Mising name <nguyenntk> | ||||||
| Component: | Core | Assignee: | Stephan Eberle <stephaneberle9> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | idydieng, quoclan, r.sezestre, stephaneberle9 | ||||||
| Version: | 0.7.0 | ||||||||
| Target Milestone: | 0.7.0 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
nguyenntk Mising name
Created attachment 201911 [details]
Modified classes
- Classes modified:
org.eclipse.emf.edit.command.DragAndDropCommand
org.eclipse.sphinx.emf.explorer.BasicDropAdapterAssistant:
- Edited methods to set the dragged object will become a child element, not a sibling element of the target object:
promptAndExecuteDropMove
prepareDropInsert
(In reply to comment #1) > - Classes modified: > org.eclipse.emf.edit.command.DragAndDropCommand > org.eclipse.sphinx.emf.explorer.BasicDropAdapterAssistant: We cannot modify EMF code in Sphinx. Only Sphinx classes can be modified. Please revise the patch and/or submit a bug to EMF if you think that the DragAndDropCommand modification is a must to have. The root cause of this bug is: BasicDropAdapterAssistant doesn't use correct location. Drag and drop, except for move, copy, link; there is another factor: location. Location is a "relative vertical location of the drag operation", and its range is from 0.0 to 1.0. Based on this location, DragAndDropCommand will understand to: - location (<=0.2 or >=0.8): * do DROP_INSERT first, if not ok, do DROP_ON - location (>0.2 and <0.8): * do DROP_ON first, if not ok, do DROP_INSERT with: * DROP_INSERT: find a parent of target element, then paste source as child of this parent --> pasted source will be a sibling element of target * DROP_ON: paste source as child of target element --> pasted source will be a child element of target Currently, BasicDropAdapterAssistant provides the wrong "location" to create DragAndDropCommand: 1. In validateDrop() method, it passes "0.0f" as location to create DragAndDropCommand 2. In handleDropCopy() and handleDropMove() methods, it uses "dropAdapter.getCurrentLocation()" (and this method returns integer value ranges from 1 -> 4) Therefore, it always do DROP_INSERT first --> we'll get "pasted source is a sibling element of target" in case type of target element and its parent element is the same (for ex.: ARPackage element in Autosar) Solution: - Define new attribute "location=0.5f" and use this attribute for all statements to create DragAndDropCommand Provided patch is in attachment. Created attachment 202299 [details]
BasicDropAdapterAssistant.java.patch
(In reply to comment #3) > Solution: > - Define new attribute "location=0.5f" and use this attribute for all > statements to create DragAndDropCommand > > Provided patch is in attachment. Sounds good to me. Am I right that this second patch is a replacement for the first one and removes the need to modify EMF's DragAndDropCommand? If yes then mark the first patch as obsolete, please. (In reply to comment #5) > Sounds good to me. Am I right that this second patch is a replacement for the > first one and removes the need to modify EMF's DragAndDropCommand? Yes, it is (just apply the second patch to fix this bug, no need to modify DragAndDropCommand) > If yes then mark the first patch as obsolete, please. Sorry, I don't know how to mark first patch as obsolete :(, would you mind to help me? (In reply to comment #6) > (In reply to comment #5) > > Sounds good to me. Am I right that this second patch is a replacement for the > > first one and removes the need to modify EMF's DragAndDropCommand? > Yes, it is (just apply the second patch to fix this bug, no need to modify > DragAndDropCommand) > > > If yes then mark the first patch as obsolete, please. > Sorry, I don't know how to mark first patch as obsolete :(, would you mind to > help me? Click on Details of relevant patch (https://bugs.eclipse.org/bugs/attachment.cgi?id=201911&action=edit), then check "obsolete" button and submit. Fixed by applying proposed 2nd patch. Added some overriding points so as to enable clients to subclass and customize the BasicDropAdapterAssistant wrt drop location and drag and drop operations. Thanks again for this very valuable contribution! Mass-closing Resolved tickets |