Community
Participate
Working Groups
I tried to copy a package.html file from one package to another using the "copy" menu entry in the packages view. The destination package already had a file called package.html so I was presented with a "Duplicate names" dialog. The dialog has two radio buttons, one for "replace element" and one for "rename to". Issues: - The replace button is grayed out - "Rename to" is ambiguous. Am I renaming the thing being copied or the file already at the destination. Since I actually wanted to overwrite the file and the rename renames the file being copied, I could not accomplish the task. Note that the copy action from the navigator works as desired. NOTES: KH (6/12/2001 7:11:31 AM) Moving to JUI for comment.
moved to 'active'
PRODUCT VERSION: 122 win2k ntfs
reorg actions got reworked and are now consistent with the navigator.
20020115: Not consistent: Copying files to location where filenames already exists Navigator View: Drag and Drop: Asks "Would you like to overwrite it?" yes/no/yes to all/cancel Copy in context-menu: Asks (for each file) "Do you wish to overwrite?" yes/no. But pressing 'no' for one file cancels the copy for the remaining files. Java Package View: Drag and Drop: Asks "Would you like to overwrite?" yes/yes to all/no/cancel Compared to Drag and Drop in Navigator View: Missing "it" after overwrite and different order of the buttons. Copy in context-menu: Creates "Copy of" files, without warning that files already exist.
Adam I know that we have decided to do it like this, but we need to revisit, let's discuss.
agree on everything except of the 'Copy of' behavior - it was different in the navigarot before and i believe it was better. users _must_ have an easy way to create a copy of a file - the navigator has just removed that feature. well, i'm sure there was *a* reason. but we know how painful it is to live without the ability to duplicate files (think about our test resources).
Erich, please see my comment above
The problem is that with our current logic, you CANNOT replace a file when doing a copy. This is a common scenario. The replace scenario is tedious since the user will have to rename the file manually. I understand that replace corresponds to a rename which involved refactoring. We need a solution where the user can replace a file in the packages view. It turns out this not only the navigator, explorer has the same behaviour.
hmm, strange - my Explorer creates a 'copy of' file. we need a solution where a user can both: *create a copy* and *replace*. what we have now allows the former but not the latter, what the navigator has - the other way round. i just discovered that the navigator is totally inconsistent there: in the d'n'd mode it asks you to replace, with a dialog - it creates a 'copy of' file. we need something significantly better here.
If we are better we have to talk to the UI team. The end goal is that we are consistent.
OK there are two scenarios which have to handled differently 1) copy from A to B (that's what this BR is about) [bug] ==> User must be asked "overwrite yes/no" 2) copy from A to A [works] ==> Copy of... can be produced without dialog
the is for navigator bug 13869
do we synch with the navigator or the explorer?
*** Bug 13213 has been marked as a duplicate of this bug. ***
if this is to be fixed it must be fixed for all stuff that can be moved - cus, packages, source folders, resources blocked for now - see bug 15192
closing this one as fixed (original bug was for files) - bug 15192 remains open, however and bug 13869 in the workbench as well - we're consistent with the explorer now
