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 better utilize the cut, copy, and paste throughout all parts of the workbench. These actions can be regarded as the keyboard equivalent of drag and drop.  Wherever drag and drop is available the Cut, Copy, and Paste actions can and should be available.  Currently, there is little consistency of use of the two in any given part of the Resource perspective (minimally), if not throughout the workbench. 


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

The Details

Problems

  1. Not consistently implementing Cut, Copy, and Paste where drag and drop implemented (e.g. Navigator, Tasks).
  2. When Copy is implemented, Cut and Paste are not; this does not make sense (e.g. Navigator).
  3. Requiring user interaction in copy implementation; using dialogs to copy resources (again, see Navigator)
  4. Need to be able to Cut, Copy, Paste
    1. within a workspace
    2. between workspaces
    3. between the workspace and other applications
  5. Need make sure we have transfer types to cover all known copy-able objects in the Resource perspective; this will be useful for those who want to use the clipboard to implement cut, copy, paste.
  6. Need to implement re-usable cut, copy, paste action handlers for all known objects in all views of the Resource perspective.

Background

The most interesting case (for the UI team) of the Cut, Copy, Paste implementation is in the Navigator.  The best way to utilize Cut, Copy, Paste and be consistent with drag and drop is to use the system clipboard to transfer resources within a workspace, between workspaces, and between a workspace and another application.  Not all ISVs who implement Cut, Copy, Paste may want to or will be able to use a conceptual clipboard to perform these actions, so we will not impose this restriction upon everyone implementing these actions. 

 

The clipboard model is fairly well understood by most users; it is frequently 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 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
  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).  When one implements a transfer type, they must be sure not to lose any information pertaining to the object being transferred.  It does not appear that additional transfer types are required to complete the transfer story for objects that exist in the Resource perspective. 

 

An important point to note is that 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. 
 

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

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.

Problems with Solution

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 than with the old dialog solution.  There are several things we can do to copy a project using the Navigator’s new semantics of cut, copy, and paste of resources, none of which actually require fewer steps than the current implementation.  First, 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:

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. 

Maybe the Core team’s work on the import/export format for projects will help us here?  Need to check with Core to see if this is still in the works.

·        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

If you have serious concerns don't wait until there is a vote - speak up now!
 
 

RFC Termination Date

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