Community
Participate
Working Groups
I copy classes often. Actually, I usually copy the same little class (named "AAATestTemplate" - it contains the basics to write a little stand-alone SWT class) to some new class, then I go edit the new class, and run it. Of course, Copy... now only creates a new class called "CopyOfAAATestTemplate". You used to be able to specify the name. So I have to do a two-step process all the time - Copy... then Rename... Please add a "New name:" text field to the Copy dialog (that currently asks for the Copy destination). You can populate this text field with the "CopyOf<SomeClass>" name default. This would allow the user to do a Copy... in one time-saving step.
The behaviour is consitent with the Navigator. If we are going to change this, the Navigator should follow the same style. Kevin, what is the platform opinion to this ?
This is *not* the same operation as in MS Explorer - you already have a dialog! Once this paradigm has been broken, there is no need to stick to the "people are used to it this way" excuse. OK, maybe "file-based" people are used to copying a file to a CopyOfFile and then renaming it (without the dialogs), but IDE people are NOT used to having to perform 2 entirely separate steps to copy a class. This is just silly. There is already a dialog, just add the "Rename to:" field. Populate it with "CopyOfFile" to begin with - the user can change it right there if they want to (and who ever wants to keep "CopyOfFile" as a real name?) I *almost always* start a class by copying another class. I am annoyed every single time. I have to go find the CopyOfFile class in the sort order (and if there are a lot of classes in your package, this will invariably cause you to scroll - but only after you hapen to guess or recall that "oh yeah, it gets copied to 'CopyOfFile' and I have to go look for it". After you find it you have to select it and pop up the context menu again (haven't I already done this?) and select Rename... and get another dialog and then finally you can type in the real name of the class - even though you knew what name you were choosing back 7 steps earlier when you were staring at the barren Copy... dialog wondering where to type in the new name. This is an unbelievably annoying number of steps and mental context switches for a very common operation, and I have just done it one too many times - sorry about the annoyance showing through in my typing.
I agree this is annoying, particularly for the "clone a new CU" case. Platform UI is considering going with clipboard-based cut/copy/paste. Actually, in the Navigator we'll most likely have just have copy and paste, with move still using a dialog. We would need the extra clipboard callback from SWT to properly handle delayed cut. If we go this way, JDT should follow suit and Car's issue will be addressed. If not, we should add the new name field to the dialog in Platform UI (and JDT should follow suit if needed).
Now that Copy in the Navigator uses the clipboard, there is no longer any reason for the Java Copy to try to look the same as Navigator - they are totally different. So once again, I would like to ask for a New Name text field in the Java Copy dialog so that copying a cu (or in our case, a .classpath file) does not have to be a 2-step process.
Randy brings up some good points: - this is only a problem when you are copying something to the same destination (which I do a lot) - if there are multiple files selected, may need to ask multiple times - if JDT does decide to go with the clipboard file copy strategy, then a dialog can be brought up on paste My personal preference is still to do as few operations as possible when I am copying a file to the same directory, i.e. A common operation for the SWT team is to copy .classpath_win32 to .classpath. With the clipboard strategy, I would have to select .classpath_win32, pop up dialog & select copy, scroll back up to the project and select that (because paste is disabled until I select a destination), then paste, then scroll back down to the "Copy of .classpath_win32" file and select it, then say Rename. I feel that this is too many mouse moves and scrolls required for a simple Copy operation.
Randy has other good ideas in http://bugs.eclipse.org/bugs/show_bug.cgi?id=9929
for consideration after 2.0 i have 3 arguments: 1. platform does not let you rename on copy (ok, it's called 'paste' now) 2. OS (win) does not let you rename on copy 3. the UI becomes problematic in the multiple-selection case (vaj showed a series of dialogs - which we'd like to avoid) for 2.0 we'll try to mimic the platform with cut/copy/paste actions.
I agree with Carolyn - the current solution is too many steps. I would like to see an option like the old one from VAME that involves one menu click or hot key, and typing in the new name. When I copy a class, the CopyOf name is not useful to me since I always want to provide a name that means something, so the *exception* to the rule is when I don't rename the class. Since it's more likely to want to give the new object a new name (I don't like how Windows does it either), I suggest we also provide a "CopyAs..." or "CopyTo..." menu option that allows one to pick a new class name. Carolyn's suggestion is good too - that a dialog be presented on paste. This can be an optional feature that is turned off by default, if being consistent with the Windows motif (no pun intended) is desirable. Yet another way to handle this problem is to provide the VA Java mechanism of changing the class name directly in the source code, and having it create a new class without removing the old CU. This could be implemented via Quickfix - currently Quickfix suggests renaming the CU to match the class, but another choice could be added to the context menu to create a new CU with that name and keep the old one intact. I think I like this idea best of all, since I think it's straightforward and integrates well with the Quickfix concept.
not, however, that a strtaightforward copy is not enough. all references to the class must be renamed inside the new file. otherwise bug 5219 will be back.
reopening bug to investigate into possible solutions. Notice, that we had the dialog solution implemented in Eclipse 1.0. The issue with the dialog solution is that you can end up in a series of modal dialogs which is unpleasant. If we go ahead on this, then the Navigator should use the same approach as well.
Erich wrote: > If we go ahead on this, then the Navigator should use the same approach as well. I don't know that they are mutually exclusive (i.e that anything existing needs to be changed). I think we could have both the copy/paste approach, *and* (as an alternative) either a) "copy as..." or b) the Quickfix approach I suggested.
I would be willing to consider the "prompt on paste" approach.
added rename support on paste (or drop in the dnd case). it is available for those cases where 'Copy Of' was created before (copying to parent resource) for implementation reasons, 'copy of' is still created when copying source folders. see bug 16296 please enter another report if you want to see a quick fix for this.
Filed bug 16374 for Navigator work.
