Community
Participate
Working Groups
Should work similar to file explorer. Should be able to rename a file by clicking on its name while it is selected. NOTES:
PRODUCT VERSION: 125 jre
*** Bug 9605 has been marked as a duplicate of this bug. ***
You do not want the rename operation to occur when a double click action occurs, so you cannot simply hook the selection event. I imagine this is the reason that there is a slight delay in IE when you attempt to rename an item by double selecting it.
Changed the code to allow a mouse click outside of the in-line editor but on the same line as the edited item to end the edit.
Backed out above fix since it is not appropriate for Linux. Fixed a bug with ending the inline rename operation --> problems with edit widget being destroyed properly and an inconsistent tree state when you click on the icon of the item being renamed (which causes a selection event for that item). Used an async in saveChangesAndDispose to fix the problem.
Reassigning to RG since he has started work on this. Randy, based on my investigation, this is a tricky problem to get correct. I was looking at using a timer to trigger the rename operation in order to deal with the double click vs. single selection of the same item. There are problems with the current released implementation. The implementation should work like the explorer does in windows (i.e. only invoke the inline rename when a click on the label of an already selected item occurs). 1) Go to resources perspective. Select a project in the navigator. Expand the project by clicking on the plus icon. The inline rename operation is invoked when it should not be. 2) Go to resources perspective. Double click on a resource to invoke its editor. Click on the navigator view. The inline rename operation is invoked when it should not be. 3) Invoke the inline rename operation. Click anywhere outside of the edit widget. This should end the rename operation (by virtue of the edit widget losing focus). There is also a general problem with ending the rename operation. If you click to the right of the item being renamed on the same line, the operation is not ended. It should be. This has to do with the fact that the edit widget is spanning the entire width of the navigator. Also note that there are Linux/non-Win issues to consider when doing this. Loss of focus works differently on Linux and focus can be customized (e.g., set to follow the mouse), so you need to make sure that any Windows solution does not break other platform rules. For example, in Windows when you click on the NavigatorView, the edit widget loses focus. In Linux this is not the case. I tried a fix for the above problem by setting focus to the NavigatorView on mouse down (so the edit would end), but this solution is incorrect for Linux.
Released change to RenameResourceAction. Didn't quite get the fix right for the bug noted above under my 2002-03-14 15:16 entry.
Defer additional work
Reopen for investigation
*** Bug 2250 has been marked as a duplicate of this bug. ***
Reassigning to Nick since he is taking ownership of Navigator
*** Bug 156530 has been marked as a duplicate of this bug. ***
Franics, this bug is targeted at the Navigator view and is a general issue for all views i.e. if we change it, other views need to adopt this to get a consistent LAF.
(In reply to comment #13) > Franics, this bug is targeted at the Navigator view and is a general issue for > all views i.e. if we change it, other views need to adopt this to get a > consistent LAF. > I agree, I might move this to the CommonNavigator. I just took over ownership of the Navigator, which means I just say that we won't do anything with it, as it's essentially replayed by the CNF.
Well, it is not just replaced by CNF. If we change this all other views that allow renaming need to be adjusted as well, hence it is a global Platform UI thing.
(In reply to comment #15) > Well, it is not just replaced by CNF. If we change this all other views that > allow renaming need to be adjusted as well, hence it is a global Platform UI > thing. > Oh yes, I completely agree. I was not intending to contradict your statement earlier.
The natural expectation for double-click is Open. There are shortcuts and easy context-menu for Rename. IF we change double-click all of a sudden to rename, it would be a major usability loss as people want to open files way more often than they want to remain them. Double-click as to remain attached to most important operation.
(In reply to Mickael Istria from comment #17) > The natural expectation for double-click is Open. There are shortcuts and > easy context-menu for Rename. IF we change double-click all of a sudden to > rename, it would be a major usability loss as people want to open files way > more often than they want to remain them. Double-click as to remain attached > to most important operation. +1.
