Bugzilla – Full Text Bug Listing
| Summary: | [DND] Drag and Drop should not select | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Peter Burka <peter_burka> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | Kevin Barnes <cocoakevin> |
| Severity: | normal | ||
| Priority: | P3 | CC: | duongn, grant_gayed, jhearn249, n.a.edgar, snorthov, stephen.francisco, veronika_irvine |
| Version: | 2.0 | Keywords: | triaged |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows NT | ||
| Whiteboard: | stalebug | ||
|
Description
Peter Burka
While the tree in the Windows explorer does not select the dragged item, the table in the right pane does. This seems quite inconsistant. I also have another bug report which points out that on Windows the selection event does not occur until after the drag finishes. It is my intent to have the selection occur (in both table and tree) before the dragging begins. I think this is the behaviour that users would expect - I think the tree behaviour in Explorer is unexpected. I disagree. Selecting the item _before_ the drag starts will make it impossible to drag a component onto an editor, as the component's own editor will open first. Since mouse down selects an item AND starts a drag and drop operation, it is logical for the selection event to be sent before the drag begins. In fact many applications make use of the current selection to determine which items are being dragged and therefore it is important that the selection happen before the drag begins. However, I think what is needed is a way for the application to tell that this selection event is associated with a Drag and Drop operation and consequently not open an editor or switch to an open editor in this case. I propose setting the event.detail field of the Selection event to indicate that a drag operation was detected. The desktop would need to check this field and not change the editor selection. Any comments Nick? With the editor linking on, the Navigator tries to ensure that if there is an editor open for an item, then it is activated when the item is selected. If we were to special case this for drag and drop, this invariant would no longer hold. It seems to be an application-specific choice as to whether the selection should change on a DND, or whether it should not. In the Explorer case, their behaviour allows you to select your destination folder on the left and have its contents appear on the right. You can then drag multiple folders from the folder hierarchy to the destination without the destination changing. It would seem to be better to allow the application to specify whether DND changes the selection or not. Although, if the selection change indicated that it was due to a DND, the app could fake this behaviour by remembering the previous selection and essentially vetoing the selection change. This feels like a big hack though. The 2.0 behaviour seems to be to open the editor before the drag operation starts. This makes it impossible to drag an open file into the contents of another editor. Perhaps Eclipse could provide some way to select an editor while dragging? In Windows, for instance, I can drag a file down to the task bar and hover over a minimized window for a second. The window will be restored, or brought to the front, allowing me to drop into it. Perhaps the same thing should happen if I hover over an editor's tab while I'm dragging? This defect is not specific to Windows NT, it happens on XP and probably all platforms as well. This problem is significant as mentioned below, because it impacts the useability of all custom editors since drag and drop is ineffectual when the default editor is currently open. It would be desirable to offer the "switch to default editor" capability as preference. Note: this problem still occurs in Eclipse 2.1 / 2.1.1 I just fixed bug 22274, which is a duplicate of this one but specific to the Navigator. It would help if SWT noted the drag in the details field of the selection event. I work around this by hooking the DragDetect event, running the editor activation code asynchronously and then checking whether a drag occured. This is a mild hack but seems safe. See org.eclipse.ui.views.navigator.ResourceNavigator.handleSelectionChanged and initDragDrop. Regarding comment 3 You're right, it's likely that there are apps that rely on the current selection to determine what is being dragged. However, it should be possible for the app to tell SWT (or an individual control) that it isn't one of those apps. In many (most?) situations, it is not desirable to change selection before the drag. We are currently writing similar hacks for other areas of the Eclipse UI. This same bug shows up in the Package Explorer, view dragging, editor dragging, etc. It would be a lot easier if SWT provided a simpler way to support dragging without a selection change. This will not be fixed for 2.1.3 because the fix would be extremely risky. The tree in the left pane of the File Explorer does not get selected until mouse up. As a result, the drag happens before the selection and the mouse up does not occur over the item so no selection happens. To change the Tree in SWT to send the Selection event on mouse up would change the current event ordering and have huge impact so it is not something we can do for 2.1.3. We will consider it for 3.0. Is this still an issue in current (3.2+) versions? No code has changed to fix it so I suspect so. Why don't you try the steps and see if it still happens and is an issue for you? Thanks. This is a one-off bulk update. (The last one in the triage migration). Moving bugs from swt-triaged@eclipse to platform-swt-inbox@eclipse.org and adding "triaged" keyword as per new triage process: https://wiki.eclipse.org/SWT/Devel/Triage See Bug 518478 for details. Tag for notification/mail filters: @TriageBulkUpdate This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |