United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4521075 : Drag gesture in JAVA different from Windows

Details
Type:
Bug
Submit Date:
2001-10-30
Status:
Resolved
Updated Date:
2005-05-23
Project Name:
JDK
Resolved Date:
2005-05-11
Component:
client-libs
OS:
windows_nt,linux,windows_xp,windows_2000
Sub-Component:
javax.swing
CPU:
x86
Priority:
P1
Resolution:
Fixed
Affected Versions:
1.4.0,1.4.1,1.4.2,5.0
Fixed Versions:

Related Reports
Backport:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
Name: ddT132432			Date: 10/30/2001


Microsoft Windows 2000 [Version 5.00.2195]
C:\>java -version
java version "1.4.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta2-b77)
Java HotSpot(TM) Client VM (build 1.4.0-beta2-b77, mixed mode)


Windows Explorer allows starting dragging a node in the file tree in one click
where 2 successive clicks are required in Java 1.4 when the default support for
DnD is enabled for an unselected node in a JTree. I suppose that it would be
the same for any other component with the default DnD support behavior.

If a JTree is used as a source for a drag operation, to drag a node from the
tree, the user needs to click once on the unselected node, release the mouse
button and click a second time, keep the button down to start dragging the node.

With Windows Explorer, if the user clicks on an unselected element and keep the
mouse button down, the user can start dragging that element immediately.
(Review ID: 134499) 
======================================================================
###@###.### 10/12/04 18:59 GMT

                                    

Comments
EVALUATION

Name: biR10147			Date: 10/31/2001

Default drag support for AWT components (Button, List, etc.)
starts a drag operation even if drag gesture was recognized on the
item which wasn't selected before the drag gesture was initiated.
However, several Swing components, including JTree, are
documented to behave by default the different way: they will
initiate the drag only if drag gesture was initiated on selection.

Documentation for JTree.setDragEnabled() says: "When automatic
drag handling is enabled, most look and feels begin a drag-and-drop
operation whenever the user presses the mouse button over a selection
and then moves the mouse a few pixels."  So the observed behavior
matches the documentation.

Anyway, it's up to Swing team to decide if they want their components
to behave this way.  Reassigning to classes_swing.

###@###.###


======================================================================

Wow, this is a popular bug. Comitting to tiger.
###@###.### 2002-10-18

Note that we should also deal with JList and JTable. I am closing a bug on JList as a duplicate of this one.
###@###.### 2003-01-16

Should investigate 4801246 along with this bug. I beleive they are related.
###@###.### 2003-01-16

The problem here is clear - our DnD implementation doesn't act as most users would expect. Under many circumstances, a mouse press should select first and then start dragging. One of the problems we need to overcome in order to fix this is the fact that DnD drag gesture recognition is handled in a separate mouse listener than the one that does selection. This is fine for the old behavior since the two mouse listeners don't need much communication - the gesture recognizer processes events first (if something is selected) and consumes them if it doesn't want the selection listener to see them.

In order to correct this bug, there needs to be a lot more communication between the selection logic and the gesture recognition logic. Sometimes a selection needs to happen first. In order to facilitate this, we will collapse the logic down into one listener. Each component will have a single selection listener. The drag gesture recognition code will be moved into a static helper class that the selection listeners can call into _when_appropriate_. Doing it this way allows the event to be seen first by the selection listener, and logic there can then decide whether or not to give the gesture recognition code a chance at the event.

- JTree will be fixed based on this approach.
- JList will be fixed based on this approach.
- JTextComponents will continue to act as before, only starting a drag when something is already selected. This is what is expected for text. However, the text DnD recognition code will be tweaked to use the new helper class.
- JTable will continue to act as before since it is often used in a spreadsheet context. JTable supports dragging to select ranges of cells and therefore it would be wrong to begin a drag unless something is already selected. This is consistent with what other spreadsheet applications do. However - when JTable is used for File selection in JFileChooser, it will be fixed as mentioned above.
###@###.### 2004-05-11

When JTable is in SINGLE_SELECTION mode (for both rows and columns), it's really being used more like a list component. Therefore, my current thinking is that I'll make it support dragging on the first press (like JTree and JList). We'll have to see how this works out.
###@###.### 2004-05-18

Note: It looks like I'll be fixing 4501652 as a side effect of fixing this. If so, I'll close that bug as a duplicate when this is done.
###@###.### 2004-05-18

4501652 will NOT be fixed by this bug. It will be fixed by another fix in tiger. See that bug for details.
###@###.### 2004-06-10

Unfortunately, the fix for this bug did not make Tiger. We continue to make fixing this bug a major priority and the lack of fix to date certainly does not stem from non-interest. The major problem still to overcome is how to solve this in a way that is backward compatible. One of the issues that was encountered is that JTree and JTable allow customization of what mouse clicks start an edit. With this logic being pluggable, it makes it extremely difficult to write drag detection logic in the correct way. It is my current belief that the fix to this bug will require making some assumptions about what developers might do. Unfortunately, that's not something that was safe so late in Tiger. I continue my efforts...
###@###.### 10/12/04 18:59 GMT

Fixing this bug is my number one priority for Mustang. I have continued with my previous work and have come even farther. I believe the implementation to be done for JTextComponents, JList and JTable. JTree is next, and I begin work immediately. In order to make JTable work correctly, I had to make some changes in behavior when getDragEnabled() is true:

1) Cell editing will no longer start on mouse presses. It will start only on mouse releases.
2) The value of CellEditor.shouldSelectCell() will be ignored in that cells will always be selected. This is necessary, otherwise they could never be dragged. The method WILL still be called, however, to ensure backward compatibility for those that expect it to be called after editing starts.
###@###.### 2005-04-21 18:55:17 GMT

I've now completed the implementation for JTree. I've made similar changes to those made in JTable that change the behavior when getDragEnabled() is true. That is, cell editing will start on mouse releases. But it will only start if no selection change was made by the press. This is to remain compatible with DefaultTreeCellEditor. Also, the value of CellEditor.shouldSelectCell() will also be ignored in that cells will always be selected. This is for the same reasons outlined above.

Lastly, as part of this fix, I've also made some changes to the Metal version of JFileChooser. It will now behave much more like the Windows L&F JFileChooser in terms of selection, activation, and drag recognition.
###@###.### 2005-04-27 16:40:42 GMT

This change will be backported to a 5.0 update release, to be enabled by a system property, "sun.swing.enableImprovedDragGesture". Example:

java -Dsun.swing.enableImprovedDragGesture APP_CLASS_NAME

###@###.### 2005-05-03 17:15:56 GMT
                                     
2005-05-03



Hardware and Software, Engineered to Work Together