|Re: [platform-ui-dev] RFC: Cut, Copy, Paste Proposal (end date = 12/03)|
Here are my commentsTitle: Cut Copy Paste
Cut Copy Paste - Draft 1
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.
Issues not covered or unclear
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.
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
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:
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).
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:
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.
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).
<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.
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.
If the API
remains what will be its behavior. Will it map to the new approach, or will
dialogs result? Ideally the former
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
To confirm it means copying an object in the bookmark means copying the bookmark itself and not copying the object it bookmakrs - right?>
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>
Back to the top