["Greg Adams/OTT/OTI" <Greg_Adams@xxxxxxx>]

Here are my comments

Title: Cut Copy Paste

  

Proposal 

RFC

Cut Copy Paste - Draft 1

Summary

The Eclipse workbench defines global actions for Cut, Copy, and Paste. The active part in a workbench page is able to supply an action handler for these actions and thus define what they do. The default text editor and the java editor perform the expected textual cut, copy, and paste (to and from a conceptual clipboard) in response to these actions. However, in the resource navigator cut and paste are not implemented while copy opens a dialog to perform a copy operation. The workbench needs to define the semantics of cut, copy, and paste and extend the use of these actions throughout the workbench. These actions should be regarded as the keyboard equivalent of drag and drop.

By Randy Giffen and Karice McIntyre, OTI
Last Modified: November 23, 2001
 

<Greg>

• I agree with overall direction/intent.

Issues not covered or unclear

• Inconsistent behavior of accelerator response. Navigator responds to F2, packages view does nothing. (at least in 1.0)
  
  
• Hitting F2 in Navigator to rename then doing Ctrl+C causes it to think it should copy the resource rather than the name.
  
  
• Moving projects - this operation does not seem to make sense (in its current form). All other move operations mean move the resource around within the workspace (i.e. to another project, folder). Yet move on a project mean move it around in the file system. This is subtle. Yes all files etc are in the file system can thus you could argue that the two are physically doing the same thing but this is not really true because the navigator presents a workspace. It is not a file explorer on the OS.
  
  The current move is really a change location and should be in the properties dialog.
  
  
• Seems like some of the views are not discussedl, properties, outline, bookmark (this partly is). Also what other views contributed by other parts of the platform (ant, team) - these also need to be good citizens - make sure they realize to fix theirs.
  
  
• Can a selection be heterogeneous folder & file.
  I saw Dirk's note on this (11/29) but I didn't follow why his case was more complicated it appeared to just be plain files.
  
  
• Is there intent to support drag/drop within the defalut text editor to rearrange trext -- (personally I never liked that feature of some editor - I tend to do it by accident)
  

• When a cut operation is in progress will the icon be shadowed/grayed - or will it be immediately removed
  
  
• If a cut does not immediately remove it, can I cancel the cut (e.g. using escape)? I vaguely recall SWT has grief with delete and escape - but imho if this is the case they earn a pr.
  
  
• Will our text editor copy text in a rich form including colors etc. Thus if I copy java code and paste it to word it would look identical including colors?
  
  
• I assume I can copy a project, folder, or file between two running versions of eclipse - this would be bogus if we can't
  
  
• Is there any override confirmation if the paste will oveeride an existing file.
  
  
• When an object has multiple formats on the clipboard what order do we look at them for. For example: Presumably a task view for example would look for a marker format first, failing that it could take a text format and create a task from it?
  
  
• If I copy a resource do its markers go with it. Presumably not since they are not actually part of that resource.
  However I assume metadata that is effectively part of the object (e.g. project natures) is copied.
  
  
• Suppose I copy a problem from the task list. Can I paste it back in later - presumably not - but there is not mention for deny cases
  
  
• I assume the behavior will be the same on all platforms.
  
  
• Mcq indicates Linux does not have cut on its file explorer. I'm not a linux person & don't have it in front of me - but this sounds rather inconsistent with how it likely works in other places not related to files. Also keep in mind we are look at it for more than just files so using the file explorer is not a true comparison. In addition I would argue that if the linux model is inconsistent (I need to go look) then that's simplicity for the sake of coding not the user.
  
  

</Greg>

---

The Details

Problem

The use of a conceptual clipboard to support the actions of Cut, Copy, and Paste is a powerful UI feature that is currently underutilized in the eclipse workbench. Moreover, there is a strong correlation between this feature and the Drag and Drop feature. In general, where one is supported, the other should be supported as well. Currently Drag and Drop is supported in places (ex. resource navigator) where Cut, Copy, and Paste are not. To compound the problem, in the resource navigator we are using the copy global action to open a dialog based copy that is not clipboard related.

 

<Greg>

Agreed - dialogs should not be opened on copy. I think Nick (NE) suggested dialogs on paste to refactor but I would be concerned this would be too "in your face" for users.

I am ok with it in the exception case (e.g. data overwride like file conflict) but each time ... that can get tedious.

 

We need to encourage ISV's not to do this. It's too bad there is no way to prevent this - e.g. by the workbench's copy doing all the actual work and simply asking for the target part to just supply the transfer format. That is, the targeted part doesn't actually get to control the entire action. (of course that would also be a breaking change)ss
</Greg>

Background

The clipboard model is fairly well understood by most users. Frequently it is used to support text editing. Its use can be extended however, to support the idea of putting objects such as files on a clipboard (ex.MS File Explorer). Moving and copying files for example, can be achieved without requiring the use of a dedicated dialog that typically is used to indicate the destination of the operation.

The underlying clipboard support in SWT uses the concept of a Transfer (org.eclipse.swt.dnd.Transfer). A Transfer is essentially code that knows how to move a something on and off the clipboard as bytes (note it may only put a reference on the clipboard such as a filename). Transfers have a stateless singleton instance accessed via a static getInstance method. SWT provides the following concrete types of transfers:

1. TextTransfer - used to transfer plain text
2. RTFTransfer - used to transfer text with rtf format
3. FileTransfer - used to transfer files

 
The workbench defines the following transfer types:

1. MarkerTansfer - used to transfer a marker
2. PluginTransfer - used to support the drop action extension
   
   <Greg> I am not sure what this one means/does.
   The name is really misleading unless its actually copying a plugin.
   </Greg>
   
3. ResourceTransfer -used to transfer an IResource (includes path and type information)

Of course if a plugin wants to transfer an object that is not supported by one of the currently existing Transfer classes, a custom transfer can be implemented (see  org.eclipse.ui.part.ResourceTransfer as an example).
<Greg>

• Hopefully writing these transfer types is trivial. If not then ISV's won't write them.
  
  
• Are there other precanned types we need to provide?

</Greg>

An important point to note is more than one type of transfer can be placed on the clipboard at a time. For example, performing a copy in the Navigator should cause a ResourceTransfer, a FileTransfer, and a TextTransfer to be placed on the clipboard (see Proposed Changes item 2 below for details on each of these transfer types). The enablement of a paste action, and the type of paste that is actually performed are determined by the target of the paste based on:
    1) its state (ex. current selection)
    2) the contents of the clipboard (the type of transfers available).

A frequently requested feature is the ability to copy a "selection as text" so that it can be used in a text editor. The use of a simple TextTransfer makes this easy. This should be performed by the Copy action. There is no need to define an additional "Copy Names" action as appears in the Packages view. In the case of a part using a standard JFace StructuredViewer, the copy action would use the labels of the selected items as the text to put on the clipboard but this could be customized as required.
 

<Greg>

• Is there any performance impact to placing more than one type of transfer on the clipboard.
  
  
• I agree there should not be multiple variants on copy in a menu

</Greg>

 

 

While it is beneficial to support as "high-level" a transfer as possible, there are cases where this can be annoying. For example suppose one is working in an editor that supports rich text but you want to compose a simple text note. Drag and Drop or Cut, Copy, Paste often produce a rich text entry such as a particular font or even a table. In such cases the user may resort to performing an intermediate step of transferring the contents to a simple text editor to remove the high-level information.

Proposed Changes

1) Define the Cut, Copy, and Paste global actions as only performing clipboard related actions (i.e. get rid of the dialogs currently used for copy). All implementers of action handlers for these actions must conform to this restriction. Of course this is a guideline that we would expect plugins to follow/migrate to, but they will not be broken if they do not.

 

2) Implement Clipboard based Cut Copy and Paste global action handlers for the Resource Navigator. These will be API (both for instantiating and subclassing by other plugins).
These actions will support
    a) ResourceTransfer within a workspace. That is, a transfer which preserves workspace meta data such as markers and natures.
    b) FileTansfer between workspaces and between a workspace and another application. This transfer only involves the OS file or folder (no meta data). It is similar to import/export.
    c) TextTransfer of the full path of the selected resources when performing a cut or copy.

 

<Greg> Transfer (cut/copy/paste) *must* also work between workspaces - if core/swt functionality is needed then they get the pr. Without this it doesn't it mean that if there were two separate eclipse products installed as opposed to having the two integrated, then it would be impossible to copy between them.</Greg>

 

<Greg> Copy between workspaces is also another reason to enable copy for projects, as well as copying them to a file explorer. </Greg>

 

Note: Cut will not be enabled for Projects since there is nowhere to move them to.  The Move operation will remain for projects since it changes the location of the project and is unrelated to clipboard cut, copy and paste.

<Greg>

• Can I copy a project and then go to the windows file explorer (for example) and paste it -- I should be able to.
  If so then why can't I cut the project and do the same?
  
  
• What does it mean for the trxt transfer to have the full path. Suppose I am in the navigator andselect 4 files and copy then paste it into a text editor, so I get the names of the files, or do I get their full paths? I think the former is what one would expect.
  
  
• Copy of a project should not auto rename (as indicated KLM's reply) unless I do a paste.

</Greg>

 

3) Since a move can be performed using cut and paste we would remove the Move action from the navigator. The MoveResourceAction and CopyResourceAction classes would remain since they are API but we would no longer use them ourselves in the workbench.

<Greg> Agreed.

If the API remains what will be its behavior. Will it map to the new approach, or will dialogs result? Ideally the former
</Greg>

 

4) Implement a Copy action handler for the task list that uses a TextTransfer to place a full description of the selected task on the clipboard (identical to the description obtained by dragging a task onto a text editor).  A similar text only copy action handler would be implemented for the Bookmarks view and the Property Sheet. For consistency, drag of a TextTransfer would also be implemented in these views.

<Greg>

To confirm it means copying an object in the bookmark means copying the bookmark itself and not copying the object it bookmakrs - right?>

</Greg>

 

Problems with Solution

<Greg> These don't seem so much like problems with the solution as much as a statement of missing support from other components> </Greg>

• Need API from SWT for Clipboard copy vs. Clipboard move (cut).  See Bug 5645 for more details.  Here is the short story:

1) Currently there is no way for the UI to implement (resource) cut so that it works correctly when pasting outside of eclipse (ex. paste to MS File Explorer). The problem is:
a) we have no way of indicating to MS File Explorer that it should perform a "move paste" rather than a copy paste.
b) we have no idea when a move paste occurs and thus cannot "refresh from local" (note that this is more than just updating the display, the workspace must be updated).
 A similar problem occurs when performing a file cut outside of eclipse and then pasting into eclipse. We don't know that it is a move paste.
In addition the clipboard must clear itself after a move paste.

2) The problem can be solved. SWT needs to add API to:
a) Allow us to set/detect if the contents of the clipboard are there as the result of a copy or a cut.
b) Allow us to register a listener to be notified when a paste occurs.
This api could perhaps be added to org.eclipse.swt.dnd.Clipboard but this remains to be worked out.

·        Copying of projects will actually require more steps then with the old dialog solution.  There are several things we can do to copy a project using the new semantics of cut copy and paste of resources, none of which actually require fewer steps than the current implementation.  Firstly, the user will have to select the project (no other resources can be selected), select Copy from the menu, deselect everything in the Navigator, then select Paste from the menu (that 4 steps already).  At this point, to complete the project copy, we can do one of the following: <Greg> This is ok. & it's consistent / expected </Greg>

1)      paste a copy of the project in the current location of the project (based on assumption that most often the user wants the copy of the project to be in the same location as the original) and be done with it.  If the user wants to change the location then they will have to perform a subsequent Move operation on the copy of the project.  This solution keeps consistency with cut copy and paste being clipboard related (no dialogs please).

2)      bring up the copy dialog (as it exists now) so the user can change the location of the project before the copy occurs.  This breaks with the consistency of cut copy paste being clipboard related, but requires fewer steps.  </Greg> no</Greg>

·        On a more general note pertaining to views other than the Navigator, if an implicit textual copy of the name of the selection (in the Navigator, the names of the selected resources) is placed on the clipboard as a TextTransfer (along with a any other applicable Transfers), the user could be confused as to exactly what is being copied.  For example, in the Tasks view when a task is selected and the user pops up the menu and selects Copy, how does he know what is being copied – the Task object itself or just the text?  Basically, we don’t want to create confusion for the user as to what copy actually copies in different views. 

RFC

This proposal is not currently being voted on however you should

• Provide all comments/feedback to the mailing list.
• Clearly indicate if you are fundamentally opposed to the proposal and provide reasons.

If you have serious concerns don't wait until there is a vote - speak up now! Staying silent and then casting a veto vote later isn't going to make you very popular.
 
 

RFC Termination Date

The period for comment ends 1 week from date proposal is submitted to the mailing list.